[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f11576a0911010437l45b64f64webffa649763406b1@mail.gmail.com>
Date: Sun, 1 Nov 2009 21:37:35 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Pavel Machek <pavel@....cz>
Cc: Rik van Riel <riel@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@....ul.ie>, stable@...nel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Frans Pop <elendil@...net.nl>, Jiri Kosina <jkosina@...e.cz>,
Sven Geggus <lists@...hsschwanzdomain.de>,
Karol Lewandowski <karol.k.lewandowski@...il.com>,
Tobias Oetiker <tobi@...iker.ch>,
Pekka Enberg <penberg@...helsinki.fi>,
Christoph Lameter <cl@...ux-foundation.org>,
Stephan von Krawczynski <skraw@...net.com>,
kernel-testers@...r.kernel.org
Subject: Re: [PATCH 2/3] page allocator: Do not allow interrupts to use
ALLOC_HARDER
2009/11/1 Pavel Machek <pavel@....cz>:
>> > I believe it would be better to simply remove it.
>>
>> You are against trying to give the realtime tasks a best effort
>> advantage at memory allocation?
>
> Yes. Those memory reserves were for kernel, GPF_ATOMIC and stuff. Now
> realtime tasks are allowed to eat into them. That feels wrong.
>
> "realtime" tasks are not automatically "more important".
>
>> Realtime apps often *have* to allocate memory on the kernel side,
>> because they use network system calls, etc...
>
> So what? As soon as they do that, they lose any guarantees, anyway.
Then, your proposal makes regression to rt workload. any improve idea
is welcome.
but we don't hope to see any regression.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists