Firstly, thanks for explaining this to me.. On Thu, 20 May 2004, Jake Burkholder wrote: > > > I'm not convinced that this is valid.. > > > consider.. > > > When you cycle through the processors above and remove the pointers to > > > the vmspace, then proceed to destroy this vmspace, there is nothing done > > > to make sure that the other procerssors are actually > > > not USING the page tables etc. associated with the vmspace. > > The reference count on the vmspace. > > > > > > > If we reclame the page tables.. surely there is a danger that another > > > cpu by still be using them? > > No because there is only one kernel page table and all cpus start using > it implicitly when they enter the kernel. So there are no other resources associated with a vmspace than the page table used at this point, and since they are using the special kernel page table instead, it doesn't matter if it goes away.. All that matters is that processors not try use it again if they are already in the kernel, and have a cached reverence to it.. I assume this is the scenario: processor 1 runs processA, then enters the kernel fo rsome reason becomes idle... processor 2 gets an interrupt and winds up continuing process A. processor 2 calls exit() from process A. <X> processor 2 calls wait() from process C and frees the vm. processor 1 still has a reference to process A's vmspace which has been freed. Since the vmspace is still in existence until wait() is called, removing all the other references as <X> should be safe. WHy does cpu_exit() not just do this work itself? Just because of the schedlock? All the architectures are calling a stub cpu_sched_exit() just for the sake of the sparc optimisation. DO you see this optimisation being eventually applied to other architectures? Thanks for your patience. >Received on Thu May 20 2004 - 10:47:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC