> > At the moment the only such code is that which sets up the p->p_stats
> > area.  However I have just made a kernel which puts p->p_sigacts
> > into the user area [1].  This requires sigactsinit() to be called
> > after the child's user area has been locked down.
> 
> this may not be such a good idea.  that eats either 1.5k or 2k (depending
> on whether it's a 32- or 64-bit kernel) from the kernel stack, which would
> greatly increase the likelyhood of a stack overflow.  in order to counteract
> that we'd probably have to increase the stack size, which would negate any
> benefit from making the signal info pageable.

Well, firstly, the p_sigacts structure is 2052 bytes on my x86 system.
(for some reason the kernal signal masks are 128 bits).
This means that each item in the sigapl pool costs 4k (IIRC there
was an issue on sun2 where the page size is only 2k...).

Secondly, unless the kernel is compiled with NOREDZONE, the kernel
stack doesn't use the same page as the user area (this might not
apply to all ports).

Exchanging a page of wired memory for a page of swappable memory
seems a win to me.

> perhaps a better way to reduce the memory usage of the signal info
> would be to add another layer of indirection and do the sharing and
> reference-counting on a per-signal basis as well as a per-signal-set basis.
> or maybe even instead of the per-signal-set basis, my workstation right now
> has 341 processes and 331 elements in use in the "sigapl" pool, so there's
> hardly any sharing going on at the per-signal-set level anyway.

Yes - they only share if the processes are going to share any changes.
This is probably limited to the kernel threads.

> it may even make sense to attempt to detect when unrelated processes
> can share the signal info.  I imagine that every instance of (eg.) sh or tcsh
> installs identical signal handlers that could be shared, even though
> the processes are not related.

Except that the masks get changed quite frequently, so the searches
could get quite expensive.

OTOH per signal we have:
	void	(*sa_handler)(int);
	int32	sa_mask[4];
	int	sa_flags;
	void	*sd_tramp;
	int	sd_vers;
(32 bytes for 32bit kernels and (I make it) 48 for 64bit).
For most processes and most signals non of these are ever set
to anything other than the default. So allocating a structure
per signal might be a gain... (take SIG_IGN and SIG_ERR outside).
I suspect that if sd_tramp is set, then sa_handler (and maybe sa_mask?)
could actually be kept by libc.


> I think you're right, yea.

I'm often right, one of my failings :-)


	David

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