Thread (180 messages) 180 messages, 22 authors, 2006-08-22

Re: [take5 0/4] kevent: Generic event handling mechanism.

From: Andrew Morton <hidden>
Date: 2006-08-09 08:45:59

On Wed, 9 Aug 2006 09:34:01 +0100
Christoph Hellwig [off-list ref] wrote:
On Wed, Aug 09, 2006 at 10:11:59AM +0400, Evgeniy Polyakov wrote:
quoted
On Tue, Aug 08, 2006 at 10:52:30PM -0700, David Miller (davem@davemloft.net) wrote:
quoted
quoted
Using LIST_POISON is a flag that kevent is in appropriate queue or not,
I can add some flag into the structure, but why, if it is clear just by
looking into list's pointers.
What is wrong with using list_empty() as this indicator?
RCU only replaces ->prev pointer, and list_empty(entry) checks for
entry->next == head, but actually I do not see how kevent entry can
point to itself, so I will try this.
Looking at LIST_POISON1 is still not acceptable at all.  It's an internal
implementation details that goes and comes back once in a while.  We already
had a past discussion on a use of this and it went away, maybe Andrew
can remember it.
The list_del() poisoning will dirty the cacheline which holds the
to-be-deleted list_head.  Unnecesarily.  So it's relatively expensive.

Hence it's quite legitimate to simply remove that poisoning code, and we
might choose to do that at any time in the future, or we might move it
under CONFIG_DEBUG_FOO.

So it isn't yours to play with ;)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help