Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

[Nick Piggin <nickpiggin@yahoo.com.au>]

Daniel Phillips wrote:
> Hi Andrew,
> 
> On Monday 12 July 2004 16:54, Andrew Morton wrote:
> 
>>Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>>>I don't see why it would be a problem to implement a "this task
>>>facilitates page reclaim" flag for userspace tasks that would take
>>>care of this as well as the kernel does.
>>
>>Yes, that has been done before, and it works - userspace "block drivers"
>>which permanently mark themselves as PF_MEMALLOC to avoid the obvious
>>deadlocks.
>>
>>Note that you can achieve a similar thing in current 2.6 by acquiring
>>realtime scheduling policy, but that's an artifact of some brainwave which
>>a VM hacker happened to have and isn't a thing which should be relied upon.
> 
> 
> Do you have a pointer to the brainwave?
> 

Search for rt_task in mm/page_alloc.c

> 
>>A privileged syscall which allows a task to mark itself as one which
>>cleans memory would make sense.
> 
> 
> For now we can do it with an ioctl, and we pretty much have to do it for 
> pvmove.  But that's when user space drives the kernel by syscalls; there is 
> also the nasty (and common) case where the kernel needs userspace to do 
> something for it while it's in PF_MEMALLOC.  I'm playing with ideas there, 
> but nothing I'm proud of yet.  For now I see the in-kernel approach as the 
> conservative one, for anything that could possibly find itself on the VM 
> writeout path.
> 

You'd obviously want to make the PF_MEMALLOC task as tight as possible,
and running mlocked: I don't particularly see why such a task would be
any safer in-kernel.

PF_MEMALLOC tasks won't enter page reclaim at all. The only way they
will reach the writeout path is if you are write(2)ing stuff (you may
hit synch writeout).