Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From: Tejun Heo <tj@kernel.org>
Newsgroups: linux.kernel
Subject: Re: [RFC PATCH v2 6/7] lib/persubnode: Introducing a simple  per-subnode APIs
Date: Tue, 12 Jul 2016 21:00:01 +0200
Message-ID: <rUb4t-o7-1@gated-at.bofh.it>
References: <rTNlv-1Jn-5@gated-at.bofh.it> <rTNlw-1Jn-27@gated-at.bofh.it> <rU6Rc-66R-15@gated-at.bofh.it> <rUb4t-o7-3@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 23
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1441656

Hello,

On Tue, Jul 12, 2016 at 02:51:31PM -0400, Waiman Long wrote:
> The last 2 RFC patches were created in response to Andi's comment to have
> coarser granularity than per-cpu. In this particular use case, I don't think
> global list traversals are frequent enough to really have any noticeable
> performance impact. So I don't have any benchmark number to support this
> change. However, it may not be true for other future use cases.
> 
> These 2 patches were created to gauge if using a per-subnode API for this
> use case is a good idea or not. I am perfectly happy to keep it as per-cpu
> and scrap the last 2 RFC patches. My main goal is to make this patchset more
> acceptable to be moved forward instead of staying in limbo.

I see.  I don't think it makes sense to add a whole new API for a use
case which doesn't really need it without any backing data.  It
probably would be best to revisit this when we're dealing with an
actually problematic case.

Thanks.

-- 
tejun