On Sun, Sep 28, 2008 at 05:45:25PM +0900, Izumi Tsutsui wrote: > dholland-tech%NetBSD.org@localhost wrote: > > > On Sat, Sep 27, 2008 at 04:43:12PM +1000, matthew green wrote: > > > > > > i think we should do this. > > > > Concur. > > I guess Andrew's concern is that the compat SA code > (for compatibility only for unupgradable libpthread.so) > is so large and too complex that it could still block > future SMP work for 6.0 and further. > It's fair enough if he wouldn't like to maintain it. I think removing SA when it was removed was the right thing to do. Keeping it running the whole time that all of the SMP work AD did was done probably would have bogged things down and gotten in the way. However I do not see how the SA code is currently blocking future SMP work. I have heard Andrew and others complain about SA and talk about ways it should be done. But I haven't heard explicit examples (or even mostly-explicit examples) of how the current SA code gets in the way of future work. For the record, here are the things I see the SA code touching in other areas: 1) When we got to sleep on a condvar, we may call sa_switch() instead of mi_switch(). sa_switch() will generate the blocked upcall at this point. We however no longer allocate memory. The sa code may have to drop & retake a lock for its processing, but it has correct code to detect if the sleeping thread got re-woken on the way & correctly just returns in that case. 2) Portions of the kernel know to tell the SA code not to generate a blocked upcall. 3) Signal code copes with the kernel-level signal mask being process-wide as opposed to per-thread. Since the locking is still process-wide, this has a very low impact. 4) A few other areas (timers, ktrace) know about SA-related events. 5) userret code knows to generate upcalls. Did I miss an area? I do not see how that's going to get in the way of future SMP work. Does someone else? In all honesty, we have a well-enough designed system at the moment that SA hasn't had too much impact on other areas of code. The only way I readily see at the moment that the SA code will get in the way of future SMP work is that the developers involved in said work decide to not perform said work due to the presence of the SA code. Not that the SA code really gets in the way, just that they decide to stop working due to it. That would be sad. However, if that happens, it's up to core to decide which way to go. If they decide to pull SA due to that, so be it. Take care, Bill
Attachment:
pgpzYWGM6jLkS.pgp
Description: PGP signature