From: Tejun Heo <tj@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Chris Metcalf <cmetcalf@tilera.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>, Frederic Weisbecker <fweisbec@gmail.com>, Cody P Schafer <cody@linux.vnet.ibm.com> Subject: Re: [PATCH v4 2/2] mm: make lru_add_drain_all() selective Date: Tue, 13 Aug 2013 18:33:04 -0400 [thread overview] Message-ID: <20130813223304.GF28996@mtj.dyndns.org> (raw) In-Reply-To: <20130813151805.b1177b60cba5b127b2aa6aee@linux-foundation.org> Hello, Andrew. On Tue, Aug 13, 2013 at 03:18:05PM -0700, Andrew Morton wrote: > I don't buy it. The callback simply determines whether "we need to > schuedule work on this cpu". It's utterly simple. Nobody will have > trouble understanding or using such a thing. Well, I don't buy that either. Callback based interface has its issues. The difference we're talking about here is pretty minute but then again the improvement brought on by the callback is pretty minute too. > It removes one memory allocation and initialisation per call. It > removes an entire for_each_online_cpu() loop. But that doesn't solve the original problem at all and while it removes the loop, it also adds a separate function. > I really don't understand what's going on here. You're advocating for > a weaker kernel interface and for inferior kernel runtime behaviour. > Forcing callers to communicate their needs via a large, > dynamically-allocated temporary rather than directly. And what do we > get in return for all this? Some stuff about callbacks which frankly > has me scratching my head. Well, it is a fairly heavy path and you're pushing for an optimization which won't make any noticeable difference at all. And, yes, I do think we need to stick to simpler APIs whereever possible. Sure the difference is minute here but the addition of test callback doesn't buy us anything either, so what's the point? The allocation doesn't even exist for vast majority of configurations. If kmalloc from that site is problematic, the right thing to do is pre-allocating resources on the caller side, isn't it? Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Chris Metcalf <cmetcalf@tilera.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>, Frederic Weisbecker <fweisbec@gmail.com>, Cody P Schafer <cody@linux.vnet.ibm.com> Subject: Re: [PATCH v4 2/2] mm: make lru_add_drain_all() selective Date: Tue, 13 Aug 2013 18:33:04 -0400 [thread overview] Message-ID: <20130813223304.GF28996@mtj.dyndns.org> (raw) In-Reply-To: <20130813151805.b1177b60cba5b127b2aa6aee@linux-foundation.org> Hello, Andrew. On Tue, Aug 13, 2013 at 03:18:05PM -0700, Andrew Morton wrote: > I don't buy it. The callback simply determines whether "we need to > schuedule work on this cpu". It's utterly simple. Nobody will have > trouble understanding or using such a thing. Well, I don't buy that either. Callback based interface has its issues. The difference we're talking about here is pretty minute but then again the improvement brought on by the callback is pretty minute too. > It removes one memory allocation and initialisation per call. It > removes an entire for_each_online_cpu() loop. But that doesn't solve the original problem at all and while it removes the loop, it also adds a separate function. > I really don't understand what's going on here. You're advocating for > a weaker kernel interface and for inferior kernel runtime behaviour. > Forcing callers to communicate their needs via a large, > dynamically-allocated temporary rather than directly. And what do we > get in return for all this? Some stuff about callbacks which frankly > has me scratching my head. Well, it is a fairly heavy path and you're pushing for an optimization which won't make any noticeable difference at all. And, yes, I do think we need to stick to simpler APIs whereever possible. Sure the difference is minute here but the addition of test callback doesn't buy us anything either, so what's the point? The allocation doesn't even exist for vast majority of configurations. If kmalloc from that site is problematic, the right thing to do is pre-allocating resources on the caller side, isn't it? Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-08-13 22:33 UTC|newest] Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-06 20:22 [PATCH] mm: make lru_add_drain_all() selective Chris Metcalf 2013-08-06 20:22 ` Chris Metcalf 2013-08-06 20:22 ` [PATCH v2] " Chris Metcalf 2013-08-06 20:22 ` Chris Metcalf 2013-08-07 20:45 ` Tejun Heo 2013-08-07 20:45 ` Tejun Heo 2013-08-07 20:49 ` [PATCH v3 1/2] workqueue: add new schedule_on_cpu_mask() API Chris Metcalf 2013-08-07 20:49 ` Chris Metcalf 2013-08-07 20:52 ` [PATCH v3 2/2] mm: make lru_add_drain_all() selective Chris Metcalf 2013-08-07 20:52 ` Chris Metcalf 2013-08-07 22:48 ` [PATCH v2] " Cody P Schafer 2013-08-07 22:48 ` Cody P Schafer 2013-08-07 20:49 ` [PATCH v4 1/2] workqueue: add new schedule_on_cpu_mask() API Chris Metcalf 2013-08-07 20:49 ` Chris Metcalf 2013-08-09 15:02 ` Tejun Heo 2013-08-09 15:02 ` Tejun Heo 2013-08-09 16:12 ` Chris Metcalf 2013-08-09 16:12 ` Chris Metcalf 2013-08-09 16:30 ` Tejun Heo 2013-08-09 16:30 ` Tejun Heo 2013-08-07 20:49 ` [PATCH v5 " Chris Metcalf 2013-08-07 20:49 ` Chris Metcalf 2013-08-09 17:40 ` Tejun Heo 2013-08-09 17:40 ` Tejun Heo 2013-08-09 17:49 ` [PATCH v6 " Chris Metcalf 2013-08-09 17:49 ` Chris Metcalf 2013-08-09 17:52 ` [PATCH v6 2/2] mm: make lru_add_drain_all() selective Chris Metcalf 2013-08-09 17:52 ` Chris Metcalf 2013-08-07 20:52 ` [PATCH v5 " Chris Metcalf 2013-08-07 20:52 ` Chris Metcalf 2013-08-07 20:52 ` [PATCH v4 " Chris Metcalf 2013-08-07 20:52 ` Chris Metcalf 2013-08-12 21:05 ` Andrew Morton 2013-08-12 21:05 ` Andrew Morton 2013-08-13 1:53 ` Chris Metcalf 2013-08-13 1:53 ` Chris Metcalf 2013-08-13 19:35 ` Andrew Morton 2013-08-13 19:35 ` Andrew Morton 2013-08-13 20:19 ` Tejun Heo 2013-08-13 20:19 ` Tejun Heo 2013-08-13 20:31 ` Andrew Morton 2013-08-13 20:31 ` Andrew Morton 2013-08-13 20:59 ` Chris Metcalf 2013-08-13 20:59 ` Chris Metcalf 2013-08-13 21:13 ` Andrew Morton 2013-08-13 21:13 ` Andrew Morton 2013-08-13 22:13 ` Chris Metcalf 2013-08-13 22:13 ` Chris Metcalf 2013-08-13 22:26 ` Andrew Morton 2013-08-13 22:26 ` Andrew Morton 2013-08-13 23:04 ` Chris Metcalf 2013-08-13 23:04 ` Chris Metcalf 2013-08-13 22:51 ` [PATCH v7 1/2] workqueue: add schedule_on_each_cpu_cond Chris Metcalf 2013-08-13 22:51 ` Chris Metcalf 2013-08-13 22:53 ` [PATCH v7 2/2] mm: make lru_add_drain_all() selective Chris Metcalf 2013-08-13 22:53 ` Chris Metcalf 2013-08-13 23:29 ` Tejun Heo 2013-08-13 23:29 ` Tejun Heo 2013-08-13 23:32 ` Chris Metcalf 2013-08-13 23:32 ` Chris Metcalf 2013-08-14 6:46 ` Andrew Morton 2013-08-14 6:46 ` Andrew Morton 2013-08-14 13:05 ` Tejun Heo 2013-08-14 13:05 ` Tejun Heo 2013-08-14 16:03 ` Chris Metcalf 2013-08-14 16:03 ` Chris Metcalf 2013-08-14 16:57 ` Tejun Heo 2013-08-14 16:57 ` Tejun Heo 2013-08-14 17:18 ` Chris Metcalf 2013-08-14 17:18 ` Chris Metcalf 2013-08-14 20:07 ` Tejun Heo 2013-08-14 20:07 ` Tejun Heo 2013-08-14 20:22 ` [PATCH v8] " Chris Metcalf 2013-08-14 20:22 ` Chris Metcalf 2013-08-14 20:44 ` Andrew Morton 2013-08-14 20:44 ` Andrew Morton 2013-08-14 20:50 ` Tejun Heo 2013-08-14 20:50 ` Tejun Heo 2013-08-14 21:03 ` Andrew Morton 2013-08-14 21:03 ` Andrew Morton 2013-08-14 21:07 ` Andrew Morton 2013-08-14 21:07 ` Andrew Morton 2013-08-14 21:12 ` Andrew Morton 2013-08-14 21:12 ` Andrew Morton 2013-08-14 21:23 ` Chris Metcalf 2013-08-14 21:23 ` Chris Metcalf 2013-08-13 23:44 ` [PATCH v7 2/2] " Chris Metcalf 2013-08-13 23:44 ` Chris Metcalf 2013-08-13 23:51 ` Tejun Heo 2013-08-13 23:51 ` Tejun Heo 2013-08-13 21:07 ` [PATCH v4 " Tejun Heo 2013-08-13 21:07 ` Tejun Heo 2013-08-13 21:16 ` Andrew Morton 2013-08-13 21:16 ` Andrew Morton 2013-08-13 22:07 ` Tejun Heo 2013-08-13 22:07 ` Tejun Heo 2013-08-13 22:18 ` Andrew Morton 2013-08-13 22:18 ` Andrew Morton 2013-08-13 22:33 ` Tejun Heo [this message] 2013-08-13 22:33 ` Tejun Heo 2013-08-13 22:47 ` Andrew Morton 2013-08-13 22:47 ` Andrew Morton 2013-08-13 23:03 ` Tejun Heo 2013-08-13 23:03 ` Tejun Heo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130813223304.GF28996@mtj.dyndns.org \ --to=tj@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=cmetcalf@tilera.com \ --cc=cody@linux.vnet.ibm.com \ --cc=fweisbec@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.