Hi,
> Well, PowerPC "dcbt" does prefetch() correctly, it doesn't ever raise
> exceptions, doesn't have any side effects, takes only enough CPU to
> decode the address, and is ignored if it would have to do anything
> other than load the cacheline from RAM. Prefetch streams are halted
>
> OK, 200 cycles...
>
> But what is the cost of the conditional branch you added in prefetch(x) ?
Much less than the tablewalk. On ppc64 a tablewalk of an address that is
not populated in the hashtable will incur 2 cacheline lookups (primary
and secondary buckets). This plus the MMU state
> Yeah, I'm not at all surprised. Any implementation of "prefetch" that
> doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
> them weaker for *actual* prefetching) will generally have a hard time with
> a NULL pointer. Exactly because it will try to do a totally
On Mar 08, 2007, at 02:24:04, Eric Dumazet wrote:
Kyle Moffett a écrit :
Prefetching is also fairly critical on a Power4 or G5 PowerPC
system as they have a long memory latency; an L2-cache miss can
cost 200+ cycles. On such systems the "dcbt" prefetch instruction
brings in a single
+ its done only when the path is needed.). Real filesystems probably
+ dont want to use it, because their dentries are present in global
Pedantry: it's and don't?
-Bob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, 08 Mar 2007 08:24:04 +0100, Eric Dumazet said:
>
> But what is the cost of the conditional branch you added in prefetch(x) ?
>
> if (!x) return;
>
> (correctly predicted or not, but do powerPC have a BTB ?)
>
> About the NULL 'potential problem', maybe we could use a dummy nil (but
>
On Thu, 8 Mar 2007, Eric Dumazet wrote:
>
> Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
> CC: Christoph Hellwig <[EMAIL PROTECTED]>
> CC: Linus Torvalds <[EMAIL PROTECTED]>
Acked-by: Linus Torvalds <[EMAIL PROTECTED]>
Except you should fix the subject line when you send it out to Andrew
I'm sorry about complaining again, but..
>
> + /*
> + * Some filesystems want to provide dentry's pathname themselves,
> + * instead of pre-building names at dentry creation.
> + */
It's not _some_ filesystems. If real filesystem did this we'd be in
horrible trouble. It's
Thanks again for your feedback Christoph :)
I think I addressed all your remarks.
Thank you
[PATCH] Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to build a pathname
On Thu, Mar 08, 2007 at 10:42:21AM +0100, Eric Dumazet wrote:
> @@ -1823,6 +1823,9 @@ char * d_path(struct dentry *dentry, str
> struct vfsmount *rootmnt;
> struct dentry *root;
>
> + if (dentry->d_op && dentry->d_op->d_dname)
> + return
On Thursday 08 March 2007 09:56, Christoph Hellwig wrote:
> This patch needs a lot more documentation. It needs some really big
> comments on why this should never ever be used for a real filesystem
> (real as in user mountable), and probably add an assert for that
> invariant somewhere. Please
This patch needs a lot more documentation. It needs some really big
comments on why this should never ever be used for a real filesystem
(real as in user mountable), and probably add an assert for that
invariant somewhere. Please also update Documentation/filesystems/Locking
and
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
No, I just checked, and Intel's own optimization manual makes it clear
that you should be careful. They talk about performance penalties due to
resource constraints - which makes tons of sense with a core that is good
at handling its own
On Thu, 8 Mar 2007, Eric Dumazet wrote:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
CC: Christoph Hellwig [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED]
Acked-by: Linus Torvalds [EMAIL PROTECTED]
Except you should fix the subject line when you send it out to Andrew ;)
On Thu, 08 Mar 2007 08:24:04 +0100, Eric Dumazet said:
But what is the cost of the conditional branch you added in prefetch(x) ?
if (!x) return;
(correctly predicted or not, but do powerPC have a BTB ?)
About the NULL 'potential problem', maybe we could use a dummy nil (but
mapped)
+ its done only when the path is needed.). Real filesystems probably
+ dont want to use it, because their dentries are present in global
Pedantry: it's and don't?
-Bob
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Mar 08, 2007, at 02:24:04, Eric Dumazet wrote:
Kyle Moffett a écrit :
Prefetching is also fairly critical on a Power4 or G5 PowerPC
system as they have a long memory latency; an L2-cache miss can
cost 200+ cycles. On such systems the dcbt prefetch instruction
brings in a single
Yeah, I'm not at all surprised. Any implementation of prefetch that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly because it will try to do a totally unnecessary
OK, 200 cycles...
But what is the cost of the conditional branch you added in prefetch(x) ?
Much less than the tablewalk. On ppc64 a tablewalk of an address that is
not populated in the hashtable will incur 2 cacheline lookups (primary
and secondary buckets). This plus the MMU state machine
Hi,
Well, PowerPC dcbt does prefetch() correctly, it doesn't ever raise
exceptions, doesn't have any side effects, takes only enough CPU to
decode the address, and is ignored if it would have to do anything
other than load the cacheline from RAM. Prefetch streams are halted
when
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
No, I just checked, and Intel's own optimization manual makes it clear
that you should be careful. They talk about performance penalties due to
resource constraints - which makes tons of sense with a core that is good
at handling its own
This patch needs a lot more documentation. It needs some really big
comments on why this should never ever be used for a real filesystem
(real as in user mountable), and probably add an assert for that
invariant somewhere. Please also update Documentation/filesystems/Locking
and
On Thursday 08 March 2007 09:56, Christoph Hellwig wrote:
This patch needs a lot more documentation. It needs some really big
comments on why this should never ever be used for a real filesystem
(real as in user mountable), and probably add an assert for that
invariant somewhere. Please also
On Thu, Mar 08, 2007 at 10:42:21AM +0100, Eric Dumazet wrote:
@@ -1823,6 +1823,9 @@ char * d_path(struct dentry *dentry, str
struct vfsmount *rootmnt;
struct dentry *root;
+ if (dentry-d_op dentry-d_op-d_dname)
+ return (dentry-d_op-d_dname)(dentry, buf,
Thanks again for your feedback Christoph :)
I think I addressed all your remarks.
Thank you
[PATCH] Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to build a pathname
I'm sorry about complaining again, but..
+ /*
+ * Some filesystems want to provide dentry's pathname themselves,
+ * instead of pre-building names at dentry creation.
+ */
It's not _some_ filesystems. If real filesystem did this we'd be in
horrible trouble. It's
Kyle Moffett a écrit :
Prefetching is also fairly critical on a Power4 or G5 PowerPC system as
they have a long memory latency; an L2-cache miss can cost 200+ cycles.
On such systems the "dcbt" prefetch instruction brings in a single
128-byte cacheline and has no serializing effects
On Wed, 7 Mar 2007, Michael K. Edwards wrote:
>
> People's prejudices against prefetch instructions are sometimes
> traceable to the 3DNow! prefetch(w) botch, which some processors
> "support" as no-ops and others are too aggressive about (Opteron
> prefetches are reputed to be "strong", i. e.,
On Mar 07, 2007, at 20:25:14, Michael K. Edwards wrote:
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote
In general, using software prefetching is just a stupid idea, unless
- the prefetch really is very strict (ie for a linked list you do
exactly the above kinds of things to make sure
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote
Yeah, I'm not at all surprised. Any implementation of "prefetch" that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly
On Wed, 7 Mar 2007, Anton Blanchard wrote:
>
> Funny you mention this. We found some noticeable ppc64 regressions when
> moving the dcache to standard list macros and had to do this to fix it
> up:
>
> static inline void prefetch(const void *x)
> {
> if (unlikely(!x))
>
Hi,
> Well, I hope a prefetch(NULL) is OK because we are doing millions of
> them (see include/linux/list.h :) )
Funny you mention this. We found some noticeable ppc64 regressions when
moving the dcache to standard list macros and had to do this to fix it
up:
static inline void prefetch(const
On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> I was thinking about being able to cache the name into the dentry, do you
> think it's worth the pain ? (its not SMP safe for example...)
Actually, it *can* be SMP-safe, if you do it right. Something like
len = dentry->d_name.len;
> Not only might memcpy() do a "prefetch for read" on the source for some
> architectures (which in turn may end up being slow for an address that
> isn't in the TLB, like NULL), but you depend on a very much internal
Well, I hope a prefetch(NULL) is OK because we are doing millions of them (see
On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> OK no problem here is the patch without messing f_path.mnt
All right. I like it. Definitely worth putting into -mm, or just
re-sending to me after 2.6.21 is out (I'll forget all about it otherwise).
I have one more worry, namely this::
-
On Wednesday 07 March 2007 18:45, Linus Torvalds wrote:
> On Wed, 7 Mar 2007, Eric Dumazet wrote:
> > sockets already uses file->private_data.
> >
> > But calls to read()/write() (not send()/recv()) still need to go through
> > the dentry, before entering socket land.
>
> Sure. The dentry and the
On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> sockets already uses file->private_data.
>
> But calls to read()/write() (not send()/recv()) still need to go through the
> dentry, before entering socket land.
Sure. The dentry and the inode need to *exist*, but they can be one single
static
(resending with a more convenient attachment)
Please find enclosed the following patch, to prepare this path.
[PATCH] Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to
On Wednesday 07 March 2007 18:02, Linus Torvalds wrote:
> On Wed, 7 Mar 2007, Eric Dumazet wrote:
> > I would definitly *love* saving dentries for pipes (and sockets too), but
> > how are you going to get the inode ?
>
> Don't use an inode at all.
Lovely :)
>
> > pipes()/sockets() can use
On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> Crazy ideas : (some readers are going to kill me)
First off, as noted earlier, you don't need crazy ideas.
But:
> 1) Use the low order bit of f_path.dentry to say : this pointer is not a
> pointer to a dentry but the inode pointer (with the low
On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> I would definitly *love* saving dentries for pipes (and sockets too), but how
> are you going to get the inode ?
Don't use an inode at all.
> pipes()/sockets() can use read()/write()/rw_verify_area() and thus need
> file->f_path.dentry->d_inode (so
On Wed, Mar 07, 2007 at 08:16:14AM +0100, Eric Dumazet wrote:
> Crazy ideas : (some readers are going to kill me)
>
> 1) Use the low order bit of f_path.dentry to say : this pointer is not a
> pointer to a dentry but the inode pointer (with the low order bit set to 1)
>
> OR
>
> 2)
On Wed, Mar 07, 2007 at 08:16:14AM +0100, Eric Dumazet wrote:
Crazy ideas : (some readers are going to kill me)
1) Use the low order bit of f_path.dentry to say : this pointer is not a
pointer to a dentry but the inode pointer (with the low order bit set to 1)
OR
2) file-f_path.dentry
On Wed, 7 Mar 2007, Eric Dumazet wrote:
I would definitly *love* saving dentries for pipes (and sockets too), but how
are you going to get the inode ?
Don't use an inode at all.
pipes()/sockets() can use read()/write()/rw_verify_area() and thus need
file-f_path.dentry-d_inode (so each
On Wed, 7 Mar 2007, Eric Dumazet wrote:
Crazy ideas : (some readers are going to kill me)
First off, as noted earlier, you don't need crazy ideas.
But:
1) Use the low order bit of f_path.dentry to say : this pointer is not a
pointer to a dentry but the inode pointer (with the low order
On Wednesday 07 March 2007 18:02, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Eric Dumazet wrote:
I would definitly *love* saving dentries for pipes (and sockets too), but
how are you going to get the inode ?
Don't use an inode at all.
Lovely :)
pipes()/sockets() can use
(resending with a more convenient attachment)
Please find enclosed the following patch, to prepare this path.
[PATCH] Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to
On Wed, 7 Mar 2007, Eric Dumazet wrote:
sockets already uses file-private_data.
But calls to read()/write() (not send()/recv()) still need to go through the
dentry, before entering socket land.
Sure. The dentry and the inode need to *exist*, but they can be one single
static
On Wednesday 07 March 2007 18:45, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Eric Dumazet wrote:
sockets already uses file-private_data.
But calls to read()/write() (not send()/recv()) still need to go through
the dentry, before entering socket land.
Sure. The dentry and the inode need
On Wed, 7 Mar 2007, Eric Dumazet wrote:
OK no problem here is the patch without messing f_path.mnt
All right. I like it. Definitely worth putting into -mm, or just
re-sending to me after 2.6.21 is out (I'll forget all about it otherwise).
I have one more worry, namely this::
-
Not only might memcpy() do a prefetch for read on the source for some
architectures (which in turn may end up being slow for an address that
isn't in the TLB, like NULL), but you depend on a very much internal
Well, I hope a prefetch(NULL) is OK because we are doing millions of them (see
On Wed, 7 Mar 2007, Eric Dumazet wrote:
I was thinking about being able to cache the name into the dentry, do you
think it's worth the pain ? (its not SMP safe for example...)
Actually, it *can* be SMP-safe, if you do it right. Something like
len = dentry-d_name.len;
if
Hi,
Well, I hope a prefetch(NULL) is OK because we are doing millions of
them (see include/linux/list.h :) )
Funny you mention this. We found some noticeable ppc64 regressions when
moving the dcache to standard list macros and had to do this to fix it
up:
static inline void prefetch(const
On Wed, 7 Mar 2007, Anton Blanchard wrote:
Funny you mention this. We found some noticeable ppc64 regressions when
moving the dcache to standard list macros and had to do this to fix it
up:
static inline void prefetch(const void *x)
{
if (unlikely(!x))
return;
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote
Yeah, I'm not at all surprised. Any implementation of prefetch that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly
On Mar 07, 2007, at 20:25:14, Michael K. Edwards wrote:
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote
In general, using software prefetching is just a stupid idea, unless
- the prefetch really is very strict (ie for a linked list you do
exactly the above kinds of things to make sure
On Wed, 7 Mar 2007, Michael K. Edwards wrote:
People's prejudices against prefetch instructions are sometimes
traceable to the 3DNow! prefetch(w) botch, which some processors
support as no-ops and others are too aggressive about (Opteron
prefetches are reputed to be strong, i. e., not
Kyle Moffett a écrit :
Prefetching is also fairly critical on a Power4 or G5 PowerPC system as
they have a long memory latency; an L2-cache miss can cost 200+ cycles.
On such systems the dcbt prefetch instruction brings in a single
128-byte cacheline and has no serializing effects
Eric Dumazet a écrit :
I would definitly *love* saving dentries for pipes (and sockets too),
but how are you going to get the inode ?
pipes()/sockets() can use read()/write()/rw_verify_area() and thus need
file->f_path.dentry->d_inode (so each pipe needs a separate dentry)
Are you
On Wed, 7 Mar 2007, Eric Dumazet wrote:
> I would definitly *love* saving dentries for pipes (and sockets too), but how
> are you going to get the inode ?
I was not planning to touch anything but epoll, signalfd and timerfd
files.
> pipes()/sockets() can use read()/write()/rw_verify_area()
Linus Torvalds a écrit :
I assume that the *only* reason for having multiple dentries is really
just the output in /proc//fd/, right? Or is there any other reason to
have separate dentries for these pseudo-files?
It's a bit sad to waste that much memory (and time) on something like
that. I
On Tue, 6 Mar 2007, Linus Torvalds wrote:
>
>
> On Tue, 6 Mar 2007, Davide Libenzi wrote:
> >
> > I'm OK with everything that avoid code duplication due to those fake
> > inodes. The change can be localized inside the existing API, so it doesn't
> > really affect me externally.
>
> Can you
On Tue, 6 Mar 2007, Davide Libenzi wrote:
>
> I'm OK with everything that avoid code duplication due to those fake
> inodes. The change can be localized inside the existing API, so it doesn't
> really affect me externally.
Can you try with the first patch version that doesn't do anything
On Tue, 6 Mar 2007, Linus Torvalds wrote:
>
> [ Al Viro added to Cc: as the arbiter of good taste in the VFS layer. He
> has veto powers even over my proposals ;^]
>
> On Tue, 6 Mar 2007, Davide Libenzi wrote:
> >
> > I currently have the dentry to carry the name of the file* class it is
>
[ Al Viro added to Cc: as the arbiter of good taste in the VFS layer. He
has veto powers even over my proposals ;^]
On Tue, 6 Mar 2007, Davide Libenzi wrote:
>
> I currently have the dentry to carry the name of the file* class it is
> linked to. I'd prefer to keep it that way, unless there
On Tue, 6 Mar 2007, Avi Kivity wrote:
> Right. For kvmfs this isn't a problem as there's a 1:1 relationship
> between synthetic inodes and dentries. Perhaps d_alloc_anon() could be
> extended to avoid the scan if it's a problem.
I currently have the dentry to carry the name of the file*
On Tue, 6 Mar 2007, Avi Kivity wrote:
Right. For kvmfs this isn't a problem as there's a 1:1 relationship
between synthetic inodes and dentries. Perhaps d_alloc_anon() could be
extended to avoid the scan if it's a problem.
I currently have the dentry to carry the name of the file* class
[ Al Viro added to Cc: as the arbiter of good taste in the VFS layer. He
has veto powers even over my proposals ;^]
On Tue, 6 Mar 2007, Davide Libenzi wrote:
I currently have the dentry to carry the name of the file* class it is
linked to. I'd prefer to keep it that way, unless there are
On Tue, 6 Mar 2007, Linus Torvalds wrote:
[ Al Viro added to Cc: as the arbiter of good taste in the VFS layer. He
has veto powers even over my proposals ;^]
On Tue, 6 Mar 2007, Davide Libenzi wrote:
I currently have the dentry to carry the name of the file* class it is
linked
On Tue, 6 Mar 2007, Davide Libenzi wrote:
I'm OK with everything that avoid code duplication due to those fake
inodes. The change can be localized inside the existing API, so it doesn't
really affect me externally.
Can you try with the first patch version that doesn't do anything special
On Tue, 6 Mar 2007, Linus Torvalds wrote:
On Tue, 6 Mar 2007, Davide Libenzi wrote:
I'm OK with everything that avoid code duplication due to those fake
inodes. The change can be localized inside the existing API, so it doesn't
really affect me externally.
Can you try with the
Linus Torvalds a écrit :
I assume that the *only* reason for having multiple dentries is really
just the output in /proc/pid/fd/, right? Or is there any other reason to
have separate dentries for these pseudo-files?
It's a bit sad to waste that much memory (and time) on something like
On Wed, 7 Mar 2007, Eric Dumazet wrote:
I would definitly *love* saving dentries for pipes (and sockets too), but how
are you going to get the inode ?
I was not planning to touch anything but epoll, signalfd and timerfd
files.
pipes()/sockets() can use read()/write()/rw_verify_area() and
Eric Dumazet a écrit :
I would definitly *love* saving dentries for pipes (and sockets too),
but how are you going to get the inode ?
pipes()/sockets() can use read()/write()/rw_verify_area() and thus need
file-f_path.dentry-d_inode (so each pipe needs a separate dentry)
Are you
On Tue, 6 Mar 2007, Avi Kivity wrote:
> > /* File callbacks that implement the eventpoll file behaviour */
> > static const struct file_operations eventpoll_fops = {
> > .release= ep_eventpoll_close,
> > @@ -763,15 +767,18 @@
> > * using the inode number.
> > */
> >
Davide Libenzi a écrit :
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, "[%lu]", inode->i_ino);
+ sprintf(name, "[%p]", ep);
this.name = name;
this.len = strlen(name);
Small remark : you can avoid strlen(), since sprintf
Davide Libenzi a écrit :
* using the inode number.
*/
error = -ENOMEM;
- sprintf(name, [%lu], inode-i_ino);
+ sprintf(name, [%p], ep);
this.name = name;
this.len = strlen(name);
Small remark : you can avoid strlen(), since sprintf gives you
On Tue, 6 Mar 2007, Avi Kivity wrote:
/* File callbacks that implement the eventpoll file behaviour */
static const struct file_operations eventpoll_fops = {
.release= ep_eventpoll_close,
@@ -763,15 +767,18 @@
* using the inode number.
*/
error = -ENOMEM;
78 matches
Mail list logo
