malloc(M_NOWAIT) issues.

[Max Laier]

On Monday 19 January 2004 05:13, Matthew Dillon wrote:
>     Here's what I have so far.  This does not represent any major
> operational changes yet, but I'm gearing up to some sort of solution
> for CAM and for general interrupt-time allocations.

I read through it twice, looks good!

>     What this patch does is change the VM_ALLOC_* state into a flags
> set, and augments the M_ malloc flags.  It seems to do a fair job when

Just a minor, but I'd come up with different names for the VM_ALLOC_* 
flags then. Esp. since VM_ALLOC_NORMAL has a different semantic then 
VM_ALLOC_SYSTEM and VM_ALLOC_INTERRUPT. Something to explicitly denote 
that VM_ALLOC_NORMAL will allow the use of cache pages:

VM_ALLOC_STD_DRAIN	0x00
VM_ALLOC_SYS_DRAIN	0x01
VM_ALLOC_IRQ_DRAIN	0x02
VM_ALLOC_FROM_CACHE	0x04
VM_ALLOC_ZERO		0x08
VM_ALLOC_RETRY		0x80	/* VM_ALLOC_FROM_CACHE must be set */

or something in that direction.

> I drop hw.physmem to 64m and run buildworld -j 20.  I'm trying to make
> the flags more flexible to better cover the situations that come up.
>
>     My intention is to find a solution that takes advantage of the fact
> that interrupt threads are threads.  One advantage that DFly already
> has is the fact that it should be possible to reuse pages from the
> 'cache' queue for allocations made from interrupts simply by calling
> lwkt_yield() if curthread->td_preempted is non-NULL.  This would cause
> the interrupt preemption to return to the original thread and then
> reschedule as a non-preemptive thread.  When non-preemptive it should
> be possible for an interrupt to make use of additional memory resources
> or even to block (if we are very careful, anyway).

-- 
Best regards,				| max at xxxxxxxxxxxxxx
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier at EFnet