Re: How to make warn_alloc() reliable?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 20-10-16 21:07:49, Tetsuo Handa wrote:
[...]
> By the way, regarding "making the direct reclaim path more deterministic"
> part, I wish that we can
> 
>   (1) introduce phased watermarks which varies based on stage of reclaim
>       operation (e.g. watermark_lower()/watermark_higher() which resembles
>       preempt_disable()/preempt_enable() but is propagated to other threads
>       when delegating operations needed for reclaim to other threads).
> 
>   (2) introduce dedicated kernel threads which perform only specific
>       reclaim operation, using watermark propagated from other threads
>       which performs different reclaim operation.
> 
>   (3) remove direct reclaim which bothers callers with managing correct
>       GFP_NOIO / GFP_NOFS / GFP_KERNEL distinction. Then, normal
>       ___GFP_DIRECT_RECLAIM callers can simply wait for
>       wait_event(get_pages_from_freelist() succeeds) rather than polling
>       with complicated short sleep. This will significantly save CPU
>       resource (especially when oom_lock is held) which is wasted by
>       activities by multiple concurrent direct reclaim.

As always, you are free to come up with patches with the proper
justification and convince people that those steps will help both the
regular case as well of those you are bothered with.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]