From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH vfs 1/2] lib: implement ptrset
Date: Wed, 19 Nov 2014 09:41:14 +0800 [thread overview]
Message-ID: <546BF53A.7010603@cn.fujitsu.com> (raw)
In-Reply-To: <20141118115530.GC7809@htj.dyndns.org>
On 11/18/2014 07:55 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 18, 2014 at 05:19:18PM +0800, Lai Jiangshan wrote:
>> Is it too ugly?
>
> What is "it"? The whole thing? percpu preloading? I'm just gonna
> continue assuming that you're talking about preloading. If you think
> it's ugly, please go ahead and explain why you think it is.
Sorry.
"it" = "preload"
>
> It's almost impossible to respond to your "review". It's not clear
> what your subject matter or opinion on it is. Might as well just bang
> on the keyboard randomly. When reviewing (or communicating in
> general), please try to properly form and elaborate your points.
> Other people can't know what's going on in your brain and have to
> speculate what you could have meant.
>
> This implementation of preloading an evolution of a design pattern
> which, IIRC, first started with the radix tree. The non-failing
> aspect was introduced while the pattern was being applied to idr. I
> think it's one of the better ways to implement preloading.
>
>> What will be the most important result it achieve?
>
> This is the same as other preloading. It allows pulling allocation
> out of critical section so that it can be done with more generous
> allocation mask (ie. GFP_KERNEL instead of GPF_NOWAIT). It's a common
> pattern found in data structures which may allocate memory internally
> such as radix tree or idr.
To me, this does explain why it is ugly. The "preload" trick separates one operation
(the memory-allocation) into 3 steps(functions) and creates a special critical region
which is preempt-disabled, which is non-workable-when-nested, the later drawback also
means preload can't work in softirqs/irqs...
I can't argue for existing code. I accept the prelaod in radix tree and idr.
And they are important data structures. (I mean they achieve important result)
so tricks or some thing applied to them seems some kinds of acceptable.
Even in idr, idr_alloc() includes two operations, id-allocation (includes memroy-allocation)
and id-resource-association. These two operations can be separated into 2 functions
without any "preload". (this separation is different from the one in "preload",
this possible separation makes one function only do one thing,
"preload"-approach uses 3 functions together to do one thing or 2 things.)
Thanks.
Lai
next prev parent reply other threads:[~2014-11-19 1:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 22:09 [PATCH vfs 1/2] lib: implement ptrset Tejun Heo
2014-11-13 22:11 ` [PATCH vfs 2/2] {block|char}_dev: remove inode->i_devices Tejun Heo
2014-11-18 12:10 ` Boaz Harrosh
2014-11-18 12:30 ` Tejun Heo
2014-11-20 10:42 ` Boaz Harrosh
2014-11-20 11:50 ` Tejun Heo
2014-11-20 12:36 ` Boaz Harrosh
2014-11-20 13:11 ` Tejun Heo
2014-11-20 13:39 ` Tejun Heo
2014-11-20 14:14 ` Boaz Harrosh
2014-11-20 14:19 ` Tejun Heo
2014-11-13 22:23 ` [PATCH vfs 1/2] lib: implement ptrset Andrew Morton
2014-11-13 22:27 ` Tejun Heo
2014-11-13 22:40 ` Andrew Morton
2014-11-14 13:12 ` Tejun Heo
2014-11-18 20:46 ` Andrew Morton
2014-11-18 9:19 ` Lai Jiangshan
2014-11-18 11:55 ` Tejun Heo
2014-11-19 1:41 ` Lai Jiangshan [this message]
2014-11-18 15:56 ` Azat Khuzhin
2014-11-18 17:16 ` Tejun Heo
2014-11-18 17:49 ` [PATCH vfs v2 " Tejun Heo
2014-11-25 16:37 ` [PATCH vfs " Jan Kara
2014-12-02 18:15 ` 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=546BF53A.7010603@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox