[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1503301041400.7251@gentwo.org>
Date: Mon, 30 Mar 2015 10:42:55 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Michal Hocko <mhocko@...e.cz>
cc: Peter Zijlstra <peterz@...radead.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>, hannes@...xchg.org,
Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
vinmenon@...eaurora.org, shashim@...eaurora.org, mgorman@...e.de,
dave@...olabs.net, koct9i@...il.com,
Linux Memory Management List <linux-mm@...ck.org>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd
work
On Mon, 30 Mar 2015, Michal Hocko wrote:
> Why cannot we do something like refresh_cpu_vm_stats from the IRQ
> context? Especially the first zone stat part. The per-cpu pagesets is
> more costly and it would need a special treatment, alright. A simple
> way would be to splice the lists from the per-cpu context and then free
> those pages from the kthread context.
That would work.
> I am still wondering why those two things were squashed into a single
> place. Why kswapd is not doing the pcp cleanup?
They were squashed together by me for conveniences sake. They could be
separated. AFAICT the pcp cleanup could be done only on demand and we
already have logic for that when flushihng via IPI.
--
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