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);
> > > + t
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
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.
(T
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 y
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 Op
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 Opte
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 e
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 re
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, funct
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 divide
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.
> Howev
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 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
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 n
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 stru
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 fil
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 pos
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 ever
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 that
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 di
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
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);
> > - t
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 = s
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 instances
29 matches
Mail list logo
