On Wed 22-02-17 15:16:57, Johannes Weiner wrote:
[...]
> And a follow-up: once it gives up, when should kswapd return to work?
> We used to reset NR_PAGES_SCANNED whenever a page gets freed. But
> that's a branch in a common allocator path, just to recover kswapd - a
> latency tool, not a necessity
On Wed 22-02-17 15:16:57, Johannes Weiner wrote:
[...]
> Can we simply count the number of balance_pgdat() runs that didn't
> reclaim anything and have kswapd sleep after MAX_RECLAIM_RETRIES?
>
> And a follow-up: once it gives up, when should kswapd return to work?
> We used to reset NR_PAGES_SCAN
On Wed 22-02-17 15:24:06, Johannes Weiner wrote:
> On Wed, Feb 22, 2017 at 03:16:57PM -0500, Johannes Weiner wrote:
> > [...] And then it sounds pretty much like what the allocator/direct
> > reclaim already does.
>
> On a side note: Michal, I'm not sure I fully understand why we need
> the backof
On Thu 23-02-17 10:46:01, hejianet wrote:
> sorry, resend it due to a delivery-failure:
> "Wrong MIME labeling on 8-bit character texts"
> I am sorry if anybody received it twice
>
> Hi Johannes
> On 23/02/2017 4:16 AM, Johannes Weiner wrote:
> > On Wed, Feb 22, 2017 at 05:04:48PM +080
resend it to lkml only.
Forwarded Message
Subject: Re: [RFC PATCH] mm/vmscan: fix high cpu usage of kswapd if there
Date: Thu, 23 Feb 2017 10:46:01 +0800
From: hejianet
To: Johannes Weiner
CC: linux...@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton
, Mel Gorman
Hi Michal
On 22/02/2017 11:48 PM, Michal Hocko wrote:
On Wed 22-02-17 22:31:50, hejianet wrote:
Hi Michal
On 22/02/2017 7:41 PM, Michal Hocko wrote:
On Wed 22-02-17 17:04:48, Jia He wrote:
When I try to dynamically allocate the hugepages more than system total
free memory:
e.g. echo 4000 >/p
On Wed, Feb 22, 2017 at 03:16:57PM -0500, Johannes Weiner wrote:
> [...] And then it sounds pretty much like what the allocator/direct
> reclaim already does.
On a side note: Michal, I'm not sure I fully understand why we need
the backoff code in should_reclaim_retry(). If no_progress_loops is
gro
On Wed, Feb 22, 2017 at 05:04:48PM +0800, Jia He wrote:
> When I try to dynamically allocate the hugepages more than system total
> free memory:
> Then the kswapd will take 100% cpu for a long time(more than 3 hours, and
> will not be about to end)
> The root cause is kswapd3 is trying to do rela
On Wed 22-02-17 22:31:50, hejianet wrote:
> Hi Michal
>
> On 22/02/2017 7:41 PM, Michal Hocko wrote:
> > On Wed 22-02-17 17:04:48, Jia He wrote:
> > > When I try to dynamically allocate the hugepages more than system total
> > > free memory:
> > > e.g. echo 4000 >/proc/sys/vm/nr_hugepages
> >
> >
Hi Michal
On 22/02/2017 7:41 PM, Michal Hocko wrote:
On Wed 22-02-17 17:04:48, Jia He wrote:
When I try to dynamically allocate the hugepages more than system total
free memory:
e.g. echo 4000 >/proc/sys/vm/nr_hugepages
I assume that the command has terminated with less huge pages allocated
t
On Wed 22-02-17 17:04:48, Jia He wrote:
> When I try to dynamically allocate the hugepages more than system total
> free memory:
> e.g. echo 4000 >/proc/sys/vm/nr_hugepages
I assume that the command has terminated with less huge pages allocated
than requested but
> Node 3, zone DMA
[...]
>
11 matches
Mail list logo
