From: Li Zefan <lizf@cn.fujitsu.com>
To: Paul Jackson <pj@sgi.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove unnecessary memmove() in cgroup_path()
Date: Thu, 22 May 2008 16:25:43 +0800 [thread overview]
Message-ID: <48352E07.7050709@cn.fujitsu.com> (raw)
In-Reply-To: <20080522030324.2b650f93.pj@sgi.com>
Paul Jackson wrote:
> Lai wrote:
>> memmove() is unnecessary in cgroup_path(), the following patch will remove it.
>
> True, I think -- memmove() can be removed as you suggest.
>
> However, it makes the code a little harder to read, in my opinion,
> because the meaning of the "@buf" parameter passed into cgroup_path()
> is no longer quite the same as the meaning of that same parameter,
> upon return from cgroup_path().
>
> I have a fairly consistent preference for code clarity, even if it
> means an occassional extra bit of code gets executed, unless we're
> on some code path where the performance gained from the tighter code
> is important. I don't think that cgroup_path() is on such a path;
Nor do I. cgroup_path() will be executed in 2 places. One is when you
cat /proc/<pid>/cgroup or a few other cgroup-related files in /proc,
one is when run the release agent. So I don't think the patch will
improve performance.
> however I could be wrong on that point. Did you discover this non-
> essential call to memmove() by code reading, or by observing that
> it was causing some noticeable performance loss for some situation
> that you care about?
>
> If we did go with this patch as you suggest, then I would like to
> suggest that we elaborate your explanation of what the "@buf"
> parameter to cgroup_path() means.
>
> Your patch states:
>
> + * @buf: *buf is the buffer to write the path into, and it was set
> + * to the start of the path when return
>
> I would suggest stating instead something like:
>
> * @buf: On entry, @buf is a pointer to a pointer to a buffer of
> * length @buflen into which the path will be written. In most
> * cases, excepting some trivial cases such as returning "/",
> * the path will be written into the -high- end of the buffer,
> * and the pointer to which buf points will be updated on
> * return from cgroup_path() to point to the beginning of that
> * path, somewhere within the original passed in buffer.
>
>
> One more minor suggestion ... your patch has:
> - char *pathbuf;
> + char *pathbuf, *path;
>
> and later on it has:
> - char *buf;
> + char *buf, *path;
>
> Could you use the same variable names, when referring to the same
> things, in both places? It makes the code a little easier to read.
>
> Overall, however, I am not sure I like this patch, unless you have good
> performance reasons to get rid of that memmove(). The complications to
> what the "@buf" parameter to cgroup_path() means just aren't worth it,
> in my current opinion.
>
next prev parent reply other threads:[~2008-05-22 8:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-22 7:30 [PATCH] remove unnecessary memmove() in cgroup_path() Lai Jiangshan
2008-05-22 8:03 ` Paul Jackson
2008-05-22 8:24 ` Paul Jackson
2008-05-22 8:25 ` Li Zefan [this message]
2008-05-22 8:39 ` Paul Jackson
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=48352E07.7050709@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
/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 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.