lkml.org 
[lkml]   [2003]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] __cacheline_aligned_in_smp?
Date
In message <20030113.223253.18825371.davem@redhat.com> you write:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Tue, 14 Jan 2003 12:10:12 +1100
>
> Hmm, you really want to weakly align it: you don't care if something follo
ws it on
> the cacheline, (ie. don't make it into an array, but it'd be nice if other
> things could share the cacheline) in UP.
>
> No, that is an incorrect statement.
>
> I want the rest of the cacheline to be absent of any write-possible
> data. There are many members in there which are read-only and thus
> will only consume a cacheline which would never need to be written
> back to main memory due to modification.

But it's not quite that simple, either. If we say dirty cachelines
cost twice as much as read-only ones (ie. read + write vs. read +
discard), it gives some guide. In particular, if a structure has
parts:
struct foo {
readonly R;
writeable W;
};

And it normally fits in one cacheline, but you set the alignment of W
to a cacheline, now it fits in two, you've lost. (Note, struct
tcp_hashinfo is not such a structure, this is just talking to the
gallery).

> You really don't understand what I'm trying to accomplish.

No. Thanks for the explanation.

> I want alignment on cache line boundary, and I don't want anything
> else in that cacheline.

A "read-mostly" section might be appropriate, then. Of course, you'd
have to split the structure, in that case, and it's not worth it if
there are only a few of these.

Have I finally got it through my thick skull now?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.052 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site