On Sat, 10 Mar 2007, Pavel Machek wrote:
> > Heh, this is what Al was saying ;)
> > I'm fine with that, but how about counter cycles (going back to zero)?
>
> Just use u64?
Yeah, the second patch was using an u64.
I ended up using a "class" name (signalfd, timerfd, asyncfd) as dname
entry. An
Hi!
> > > @@ -763,15 +767,17 @@
> > >* using the inode number.
> > >*/
> > > error = -ENOMEM;
> > > - sprintf(name, "[%lu]", inode->i_ino);
> > > this.name = name;
> > > - this.len = strlen(name);
> > > - this.hash = inode->i_ino;
> > > + this.len = sprintf(name, "[%p]", ep);
> > > +
Hi!
@@ -763,15 +767,17 @@
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, [%lu], inode-i_ino);
this.name = name;
- this.len = strlen(name);
- this.hash = inode-i_ino;
+ this.len = sprintf(name, [%p], ep);
+ this.hash = 0;
Please don't
On Sat, 10 Mar 2007, Pavel Machek wrote:
Heh, this is what Al was saying ;)
I'm fine with that, but how about counter cycles (going back to zero)?
Just use u64?
Yeah, the second patch was using an u64.
I ended up using a class name (signalfd, timerfd, asyncfd) as dname
entry. An
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
> I rewrote the reciprocal_div() for i386 so that one multiply is used.
>
> static inline u32 reciprocal_divide(u32 A, u32 R)
> {
> #if __i386
> unsigned int edx, eax;
> asm("mul %2":"=a" (eax), "=d" (edx):"rm" (R),
On Tue, Mar 06, 2007 at 21:20:33 +0100, Eric Dumazet wrote:
...
I rewrote the reciprocal_div() for i386 so that one multiply is used.
static inline u32 reciprocal_divide(u32 A, u32 R)
{
#if __i386
unsigned int edx, eax;
asm(mul %2:=a (eax), =d (edx):rm (R), 0 (A));
Eric Dumazet wrote:
Linus Torvalds a écrit :
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so "numbers talk,
bullshit walks".
Linus Torvalds a écrit :
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so "numbers talk,
bullshit walks". No more objections.
Linus Torvalds wrote:
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so "numbers talk,
bullshit walks". No more objections.
On Tue, 6 Mar 2007, Eric Dumazet wrote:
>
> I did a user space program, attached to this mail.
>
> I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so "numbers talk,
bullshit walks". No more objections.
(That said, I bet
Eric Dumazet a écrit :
On Tuesday 06 March 2007 18:28, Eric Dumazet wrote:
On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
Using reciprocal divides permits to change each divide by two
multiplies, less expensive on current CPUS.
Are you sure?
I am going to test this, but at least on
On Tuesday 06 March 2007 18:28, Eric Dumazet wrote:
> On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
>
> > > Using reciprocal divides permits to change each divide by two
> > > multiplies, less expensive on current CPUS.
> >
> > Are you sure?
>
> I am going to test this, but at least on
On Tue, 6 Mar 2007, H. Peter Anvin wrote:
> Eric Dumazet wrote:
> >
> > For epoll, I suspect this is harmless : Programs dont allocate epolls fd
> > every milli second, but at startup only.
> >
> > For pipes/sockets, using a 64 bits would be problematic, because sprintf()
> > uses a divide for
Linus Torvalds wrote:
On Tue, 6 Mar 2007, Eric Dumazet wrote:
Something like :
[PATCH] : Use reciprocal divides in sprintf()
Try this on Core 2, and I suspect that you'll find that the hardware is
actually *faster* than doing the shift/test, function call and the
two multiplies.
Using
On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
> On Tue, 6 Mar 2007, Eric Dumazet wrote:
> > Something like :
> >
> > [PATCH] : Use reciprocal divides in sprintf()
>
> Try this on Core 2, and I suspect that you'll find that the hardware is
> actually *faster* than doing the shift/test,
On Tue, 6 Mar 2007, Eric Dumazet wrote:
>
> Something like :
>
> [PATCH] : Use reciprocal divides in sprintf()
Try this on Core 2, and I suspect that you'll find that the hardware is
actually *faster* than doing the shift/test, function call and the
two multiplies.
> Using reciprocal
Linus Torvalds wrote:
However, this could be optimized. I think right now sprintf() uses a generic
divide-by-base, but a divide by 8 and 16 can of course be handled with a
shift, and divide by 10 can be replaced with a multiplication by
0x1999ULL on most architectures.
Nope. You
On Tuesday 06 March 2007 17:28, H. Peter Anvin wrote:
> Eric Dumazet wrote:
> > For epoll, I suspect this is harmless : Programs dont allocate epolls fd
> > every milli second, but at startup only.
> >
> > For pipes/sockets, using a 64 bits would be problematic, because
> > sprintf() uses a divide
On Tue, 6 Mar 2007, H. Peter Anvin wrote:
>
> That's true for *any* sprintf(), though. sprintf() converts all its arguments
> to 64 bits.
Well, it very much uses "do_div()", so that it can do a
64 / 32 -> (div64,mod32)
divide, which is often faster than a full 64:64 divide.
>
Eric Dumazet wrote:
For epoll, I suspect this is harmless : Programs dont allocate epolls fd
every milli second, but at startup only.
For pipes/sockets, using a 64 bits would be problematic, because
sprintf() uses a divide for each digit. And a divide is slow. Ten
divides are *very* slow.
Eric Dumazet wrote:
For epoll, I suspect this is harmless : Programs dont allocate epolls fd
every milli second, but at startup only.
For pipes/sockets, using a 64 bits would be problematic, because
sprintf() uses a divide for each digit. And a divide is slow. Ten
divides are *very* slow.
On Tue, 6 Mar 2007, H. Peter Anvin wrote:
That's true for *any* sprintf(), though. sprintf() converts all its arguments
to 64 bits.
Well, it very much uses do_div(), so that it can do a
64 / 32 - (div64,mod32)
divide, which is often faster than a full 64:64 divide.
However,
On Tuesday 06 March 2007 17:28, H. Peter Anvin wrote:
Eric Dumazet wrote:
For epoll, I suspect this is harmless : Programs dont allocate epolls fd
every milli second, but at startup only.
For pipes/sockets, using a 64 bits would be problematic, because
sprintf() uses a divide for each
Linus Torvalds wrote:
However, this could be optimized. I think right now sprintf() uses a generic
divide-by-base, but a divide by 8 and 16 can of course be handled with a
shift, and divide by 10 can be replaced with a multiplication by
0x1999ULL on most architectures.
Nope. You
On Tue, 6 Mar 2007, Eric Dumazet wrote:
Something like :
[PATCH] : Use reciprocal divides in sprintf()
Try this on Core 2, and I suspect that you'll find that the hardware is
actually *faster* than doing the shift/test, function call and the
two multiplies.
Using reciprocal divides
Linus Torvalds wrote:
On Tue, 6 Mar 2007, Eric Dumazet wrote:
Something like :
[PATCH] : Use reciprocal divides in sprintf()
Try this on Core 2, and I suspect that you'll find that the hardware is
actually *faster* than doing the shift/test, function call and the
two multiplies.
Using
On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
On Tue, 6 Mar 2007, Eric Dumazet wrote:
Something like :
[PATCH] : Use reciprocal divides in sprintf()
Try this on Core 2, and I suspect that you'll find that the hardware is
actually *faster* than doing the shift/test, function call
On Tue, 6 Mar 2007, H. Peter Anvin wrote:
Eric Dumazet wrote:
For epoll, I suspect this is harmless : Programs dont allocate epolls fd
every milli second, but at startup only.
For pipes/sockets, using a 64 bits would be problematic, because sprintf()
uses a divide for each digit.
On Tuesday 06 March 2007 18:28, Eric Dumazet wrote:
On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
Using reciprocal divides permits to change each divide by two
multiplies, less expensive on current CPUS.
Are you sure?
I am going to test this, but at least on Opterons, the
Eric Dumazet a écrit :
On Tuesday 06 March 2007 18:28, Eric Dumazet wrote:
On Tuesday 06 March 2007 18:19, Linus Torvalds wrote:
Using reciprocal divides permits to change each divide by two
multiplies, less expensive on current CPUS.
Are you sure?
I am going to test this, but at least on
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so numbers talk,
bullshit walks. No more objections.
(That said, I bet you
Linus Torvalds wrote:
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so numbers talk,
bullshit walks. No more objections.
Linus Torvalds a écrit :
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so numbers talk,
bullshit walks. No more objections.
Eric Dumazet wrote:
Linus Torvalds a écrit :
On Tue, 6 Mar 2007, Eric Dumazet wrote:
I did a user space program, attached to this mail.
I rewrote the reciprocal_div() for i386 so that one multiply is used.
Ok, this is definitely faster on Core 2 as well, so numbers talk,
bullshit walks.
On Mon, 5 Mar 2007, Davide Libenzi wrote:
> This would be used for epoll, signalfd and timerfd. And the printf format
> is %llu ;)
Today is really one on those days ... %llx
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, 6 Mar 2007, Eric Dumazet wrote:
> Davide Libenzi a écrit :
> > On Mon, 5 Mar 2007, H. Peter Anvin wrote:
> >
> > > Davide Libenzi wrote:
> > > > Right now is using:
> > > >
> > > > this.len = sprintf(name, "[%u.%d]", current->pid, fd);
> > > >
> > > > That should be unique and
Davide Libenzi a écrit :
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, "[%u.%d]", current->pid, fd);
That should be unique and not have the wraparound problem. Ack?
NAK, very much NAK.
File descriptors aren't file
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
> Davide Libenzi wrote:
> >
> > Right now is using:
> >
> > this.len = sprintf(name, "[%u.%d]", current->pid, fd);
> >
> > That should be unique and not have the wraparound problem. Ack?
> >
>
> NAK, very much NAK.
>
> File descriptors aren't
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, "[%u.%d]", current->pid, fd);
That should be unique and not have the wraparound problem. Ack?
NAK, very much NAK.
File descriptors aren't file structures, they're *pointers* to file
structures.
It's perfectly
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > Since this is not actually *used* for anything but showing the fd's in
> > /proc//fd/ etc, no. In fact, an integer will wrap a *lot* less than a
> > kernel data structure will be re-used, so even with the simple "wraps
Linus Torvalds wrote:
Since this is not actually *used* for anything but showing the fd's in
/proc//fd/ etc, no. In fact, an integer will wrap a *lot* less than a
kernel data structure will be re-used, so even with the simple "wraps
every 4G uses", you're still better off.
... and if
On Mon, 5 Mar 2007, Davide Libenzi wrote:
> On Mon, 5 Mar 2007, Linus Torvalds wrote:
> >
> > It's much better to do something like
> >
> > static unsigned int epoll_inode;
> >
> > this.len = sprintf(name, "[%u]", ++epoll_inode);
> >
> > if you just need some pseudo-unique name to
On Mon, 5 Mar 2007, Davide Libenzi wrote:
> On Mon, 5 Mar 2007, Linus Torvalds wrote:
>
> > On Mon, 5 Mar 2007, Davide Libenzi wrote:
> > > @@ -763,15 +767,17 @@
> > >* using the inode number.
> > >*/
> > > error = -ENOMEM;
> > > - sprintf(name, "[%lu]", inode->i_ino);
> > >
On Mon, 5 Mar 2007, Linus Torvalds wrote:
> On Mon, 5 Mar 2007, Davide Libenzi wrote:
> > @@ -763,15 +767,17 @@
> > * using the inode number.
> > */
> > error = -ENOMEM;
> > - sprintf(name, "[%lu]", inode->i_ino);
> > this.name = name;
> > - this.len = strlen(name);
> > -
On Mon, 5 Mar 2007, Davide Libenzi wrote:
> @@ -763,15 +767,17 @@
>* using the inode number.
>*/
> error = -ENOMEM;
> - sprintf(name, "[%lu]", inode->i_ino);
> this.name = name;
> - this.len = strlen(name);
> - this.hash = inode->i_ino;
> + this.len =
ChangeLog:
- v2) Properly size the buffer. Avoid extra strlen() (Eric Dumazet)
Epoll does not keep any private data attached to its inode, so there'd be
no need to allocate one inode per fd. For epoll, the inode is just a
placeholder for the file operations and could be shared by all
ChangeLog:
- v2) Properly size the buffer. Avoid extra strlen() (Eric Dumazet)
Epoll does not keep any private data attached to its inode, so there'd be
no need to allocate one inode per fd. For epoll, the inode is just a
placeholder for the file operations and could be shared by all
On Mon, 5 Mar 2007, Davide Libenzi wrote:
@@ -763,15 +767,17 @@
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, [%lu], inode-i_ino);
this.name = name;
- this.len = strlen(name);
- this.hash = inode-i_ino;
+ this.len = sprintf(name,
On Mon, 5 Mar 2007, Linus Torvalds wrote:
On Mon, 5 Mar 2007, Davide Libenzi wrote:
@@ -763,15 +767,17 @@
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, [%lu], inode-i_ino);
this.name = name;
- this.len = strlen(name);
- this.hash =
On Mon, 5 Mar 2007, Davide Libenzi wrote:
On Mon, 5 Mar 2007, Linus Torvalds wrote:
On Mon, 5 Mar 2007, Davide Libenzi wrote:
@@ -763,15 +767,17 @@
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, [%lu], inode-i_ino);
this.name = name;
- this.len =
On Mon, 5 Mar 2007, Davide Libenzi wrote:
On Mon, 5 Mar 2007, Linus Torvalds wrote:
It's much better to do something like
static unsigned int epoll_inode;
this.len = sprintf(name, [%u], ++epoll_inode);
if you just need some pseudo-unique name to distinguish two
Linus Torvalds wrote:
Since this is not actually *used* for anything but showing the fd's in
/proc/pid/fd/ etc, no. In fact, an integer will wrap a *lot* less than a
kernel data structure will be re-used, so even with the simple wraps
every 4G uses, you're still better off.
... and if
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
Linus Torvalds wrote:
Since this is not actually *used* for anything but showing the fd's in
/proc/pid/fd/ etc, no. In fact, an integer will wrap a *lot* less than a
kernel data structure will be re-used, so even with the simple wraps every
4G
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, [%u.%d], current-pid, fd);
That should be unique and not have the wraparound problem. Ack?
NAK, very much NAK.
File descriptors aren't file structures, they're *pointers* to file
structures.
It's perfectly
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, [%u.%d], current-pid, fd);
That should be unique and not have the wraparound problem. Ack?
NAK, very much NAK.
File descriptors aren't file structures, they're
Davide Libenzi a écrit :
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, [%u.%d], current-pid, fd);
That should be unique and not have the wraparound problem. Ack?
NAK, very much NAK.
File descriptors aren't file
On Tue, 6 Mar 2007, Eric Dumazet wrote:
Davide Libenzi a écrit :
On Mon, 5 Mar 2007, H. Peter Anvin wrote:
Davide Libenzi wrote:
Right now is using:
this.len = sprintf(name, [%u.%d], current-pid, fd);
That should be unique and not have the wraparound
On Mon, 5 Mar 2007, Davide Libenzi wrote:
This would be used for epoll, signalfd and timerfd. And the printf format
is %llu ;)
Today is really one on those days ... %llx
- Davide
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
58 matches
Mail list logo
