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
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 work so
>> 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
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)) {
> >
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)) {
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 != NULL)) {
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.
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 how
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
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
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
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,
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
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
>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
> 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.
> > 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
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
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
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 instruction is
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()/unlikely()
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 eip, the
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. Internally a
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
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
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;
}
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, 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 tiniest
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
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, or
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
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
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
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 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)) {
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
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
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
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
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
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
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
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
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
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 effectively half
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 unsubscribe
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 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
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
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
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
(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
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
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
is
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 the
64 matches
Mail list logo
