Hi Paul,
Sorry about the late reply.
On Sun, 27 Mar 2005, Paul Jackson wrote:
> Jesper wrote:
> > What I'm trying to find out now is if there's a general consensus that
> > these patches are worthwile and wanted or if they are unwanted and I'm
> > wasting my time.
>
> Thanks for your good
>> I see kfree used in several hot paths. Check out
>> this /proc/latency_trace excerpt:
>
>Yes, but is the pointer being free'd NULL most of the time?
"[...]In general, you should prefer to use actual profile feedback for this
(`-fprofile-arcs'), as programmers are NOTORIOUSLY BAD AT PREDICTING
On Mon, 28 Mar 2005 21:52:57 -0500, Lee Revell <[EMAIL PROTECTED]> wrote:
> I see kfree used in several hot paths. Check out
> this /proc/latency_trace excerpt:
Yes, but is the pointer being free'd NULL most of the time? The
optimization does not help if you are releasing actual memory.
On Sun, 2005-03-27 at 12:40 -0500, Dave Jones wrote:
> On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
>
> > Well, kfree inlined was already mentioned but forgotten again.
> > What if this was used:
> >
> > inline static void kfree_WRAP(void *addr) {
> > if(likely(addr !=
On Sun, 27 Mar 2005, Dave Jones wrote:
> On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
> > Well, kfree inlined was already mentioned but forgotten again.
> > What if this was used:
> >
> > inline static void kfree_WRAP(void *addr) {
> > if(likely(addr != NULL)) {
> >
Dave Jones <[EMAIL PROTECTED]> said:
> On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
>
> > Well, kfree inlined was already mentioned but forgotten again.
> > What if this was used:
> >
> > inline static void kfree_WRAP(void *addr) {
> > if(likely(addr != NULL)) {
> >
Jesper wrote:
> What I'm trying to find out now is if there's a general consensus that
> these patches are worthwile and wanted or if they are unwanted and I'm
> wasting my time.
Thanks for your good work so far, and your good natured tolerance of
the excessively detailed discussions resulting.
Dave writes:
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
Eh .. it's well known behaviour. Bring two questions before a
committee, one for millions of dollars and the other for pocket change,
and watch the committee spend mo
Jan - please don't trim the CC lists when responding on lkml.
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send t
On Sun, 27 Mar 2005, Arjan van de Ven wrote:
On Sat, 2005-03-26 at 18:21 -0500, linux-os wrote:
On Sat, 26 Mar 2005, Arjan van de Ven wrote:
On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
Isn't it expensive of CPU time to call kfree() even though the
pointer may have already been freed?
nope
a
On Sun, 27 Mar 2005, Dave Jones wrote:
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tiniest
> blip on a real workload, o
On Sat, 26 Mar 2005, Marcin Dalecki wrote:
On 2005-03-27, at 00:21, linux-os wrote:
Always, always, a call will be more expensive than a branch
on condition. It's impossible to be otherwise. A call requires
that the return address be written to memory (the stack),
using register indirection (the st
On Sun, 27 Mar 2005 12:40:26 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tin
>Am I the only person who is completely fascinated by the
>effort being spent here micro-optimising something thats
>almost never in a path that needs optimising ?
>I'd be amazed if any of this masturbation showed the tiniest
>blip on a real workload, or even on a benchmark other than
>one crafted
On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
> Well, kfree inlined was already mentioned but forgotten again.
> What if this was used:
>
> inline static void kfree_WRAP(void *addr) {
> if(likely(addr != NULL)) {
> kfree_real(addr);
> }
> return;
> }
>Just looking at the third run, it seems to me that "if (likely(p))
>kfree(p);" beats a naked "kfree(p);" everytime, whether p is half
>NULL's, or very few NULL's, or almost all NULL's.
Well, kfree inlined was already mentioned but forgotten again.
What if this was used:
inline static void kfree_
> I added likely() and unlikely() to all tests, here are the results from 3
> runs on my box :
Any chance you could summarize what these results are, for those
of us too lazy to parse it all out? The time spent by one author
to summarize in English what the numbers state can save the time of
a
On Sun, 2005-03-27 at 15:51 +0300, Denis Vlasenko wrote:
> > > It's impossible to be otherwise. A call requires
> > > that the return address be written to memory (the stack),
> > > using register indirection (the stack-pointer).
> >
> > and it's a so common pattern that it's optimized to death. I
> > It's impossible to be otherwise. A call requires
> > that the return address be written to memory (the stack),
> > using register indirection (the stack-pointer).
>
> and it's a so common pattern that it's optimized to death. Internally a
> call gets transformed to 2 uops or so, one is push ei
On Sat, 26 Mar 2005, Lee Revell wrote:
> On Sun, 2005-03-27 at 00:54 +0100, Jesper Juhl wrote:
> > I'd say that the general rule should
> > be "don't check for NULL first unless you *know* the pointer will be NULL
> > >50% of the time"...
>
> How about running the same tests but using likely()/u
On Sat, 2005-03-26 at 18:21 -0500, linux-os wrote:
> On Sat, 26 Mar 2005, Arjan van de Ven wrote:
>
> > On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
> >> Isn't it expensive of CPU time to call kfree() even though the
> >> pointer may have already been freed?
> >
> > nope
> >
> > a call instr
On 2005-03-27, at 04:00, Horst von Brand wrote:
Needless to say that there are enough architectures out there, which
don't even have something like an explicit call as separate assembler
instruction...
The mechanism exists somehow.
Most RISC architectures are claiming a huge register set advantage
Marcin Dalecki <[EMAIL PROTECTED]> said:
> On 2005-03-27, at 00:21, linux-os wrote:
> > Always, always, a call will be more expensive than a branch
> > on condition.
Wrong.
> > It's impossible to be otherwise.
Many, many counterexamples say otherwise...
> >
On Sun, 2005-03-27 at 00:54 +0100, Jesper Juhl wrote:
> I'd say that the general rule should
> be "don't check for NULL first unless you *know* the pointer will be NULL
> >50% of the time"...
How about running the same tests but using likely()/unlikely() for the
'1 in 50' cases?
Lee
-
To unsubs
On Sat, 26 Mar 2005, linux-os wrote:
> On Sat, 26 Mar 2005, Arjan van de Ven wrote:
>
> > On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
> > > Isn't it expensive of CPU time to call kfree() even though the
> > > pointer may have already been freed?
> >
> > nope
> >
> > a call instruction is
On 2005-03-27, at 00:21, linux-os wrote:
Always, always, a call will be more expensive than a branch
on condition. It's impossible to be otherwise. A call requires
that the return address be written to memory (the stack),
using register indirection (the stack-pointer).
Needless to say that there ar
On Sat, 26 Mar 2005, Arjan van de Ven wrote:
On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
Isn't it expensive of CPU time to call kfree() even though the
pointer may have already been freed?
nope
a call instruction is effectively half a cycle or less, the branch
Wrong!
predictor of the cpu can
On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
> Isn't it expensive of CPU time to call kfree() even though the
> pointer may have already been freed?
nope
a call instruction is effectively half a cycle or less, the branch
predictor of the cpu can predict perfectly where the next instruction
Hi,
On Fri, 25 Mar 2005 17:29:56 -0500 (EST), linux-os
<[EMAIL PROTECTED]> wrote:
> Isn't it expensive of CPU time to call kfree() even though the
> pointer may have already been freed? I suggest that the check
> for a NULL before the call is much less expensive than calling
> kfree() and doing th
On Fri, 25 Mar 2005, linux-os wrote:
>
> Isn't it expensive of CPU time to call kfree() even though the
> pointer may have already been freed? I suggest that the check
> for a NULL before the call is much less expensive than calling
> kfree() and doing the check there. The resulting "double check
Isn't it expensive of CPU time to call kfree() even though the
pointer may have already been freed? I suggest that the check
for a NULL before the call is much less expensive than calling
kfree() and doing the check there. The resulting "double check"
is cheap, compared to the call.
On Fri, 25 Mar
(please keep me on CC)
kfree() handles NULL fine, to check is redundant.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm3-orig/fs/ext2/acl.c 2005-03-02 08:38:18.0
+0100
+++ linux-2.6.12-rc1-mm3/fs/ext2/acl.c 2005-03-25 22:41:07.0 +0100
@@ -194,8 +194
32 matches
Mail list logo
