tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Status of revivesa

On Sun, Sep 28, 2008 at 05:45:25PM +0900, Izumi Tsutsui wrote:
> 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
> 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 

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 

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,


Attachment: pgpzYWGM6jLkS.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index