Andrew Morton <akpm@xxxxxxxxx> writes:
>
> #ifndef GFP_READAHEAD
> #define GFP_READAHEAD 0
> #endif
>
> That's an atomic, low-priority allocation. It is expected to
> fail, and can easily do so.
Ups, you're right, of course. I totally misinterpreted gfp_mask 0x0,
forgot it means atomic.
>
> So there's your reason - this can quite easily outrun kswapd.
>
Of course.
> If we really want to do it this way (and I suspect we don't)
> then the allocation attempt should be wrapped in PF_NOWARN
> to keep the messages away.
>
That won't be of much help, as when xfsdump stucks on the page
failure, it is unkillable, and some partitions can't be cleanly
unmounted later, and other stuff gets messed up...
Messages in the kernel log are the least of our problems (also because
there's not that much of them, typicaly 1 - 10).
> And it should be changed to __GFP_HIGHMEM so XFS can perform
> readahead into highmem pages.
>
> However it is probably best to change this to just use
> mapping->gfp_mask. I vaguely recall that the nonblocking allocation
> improved performance in some situations, but it's quite possible
> that the VM problem which made that a good thing got fixed.
>
> And you really should run page reclaim for readahead - the system
> is more likely to use readahead pages in the near future than it
> is to use pages at the tail of the inactive list.
I think I'll leave it to xfs guys now to fix it properly, I don't even
understand why allocating pages for readahead needs to be atomic.
Thanks for explanation.
Regards,
--
Zlatko
|