> > Exchanging a page of wired memory for a page of swappable memory
> > seems a win to me.
> 
> exchanging a page of memory for a lot less memory would be even better, no?

true!  overlaying thereference count on (some member of) the first
array entry (signal 0 is never used) would halve the effective size of
the structure!
(Although, maybe, the pool code should allocate several pages at once
in order to reduce wastage..)


> > Except that the masks get changed quite frequently, so the searches
> > could get quite expensive.
> 
> it's p->p_sigctx->ps_* that changes frequently, not the per-signal masks.

I was thinking of code that does a sigset() for all the signals.
sigset (and friends) are used dynmically in some programs.
 
> I was thinking about your original question again, and on second thought,
> I don't see why moving cpu_fork() would help at all.  it's the last thing
> called in uvm_fork(), so the only benefit of moving it to fork1() would be
> if there was something that needed to be done after the rest of uvm_fork()
> but cpu_fork().  why would playing with signal state need to go in between?

Because you can't set up anything in the user area of the child
process until after it has been wired by uvm_fork.
Which is why the stats pointer setup is lurking in uvm_fork,
it isn't uvm code so would be better in fork1.

	David

-- 
David Laight: david@l8s.co.uk