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

Nick Piggin
2004-07-13T02:31:27Z

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).