[lkml]   [2005]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Event counters [1/3]: Basic counter functionality
Marcelo Tosatti wrote:

> What about this addition to the documentation above, to make it a little more
> verbose:
> The possible race scenario is restricted to kernel preemption,
> and could happen as follows:
> thread A thread B
> a) movl xyz(%ebp), %eax movl xyz(%ebp), %eax
> b) incl %eax incl %eax
> c) movl %eax, xyz(%ebp) movl %eax, xyz(%ebp)
> Thread A can be preempted in b), and thread B succesfully increments the
> counter, writing it back to memory. Now thread A resumes execution, with
> its stale copy of the counter, and overwrites the current counter.
> Resulting in increments lost.
> However that should be relatively rare condition.

Hi Guys,

I've been waiting for some mm/ patches to clear from -mm before commenting
too much... however I see that this patch is actually against -mm itself,
with my __mod_page_state stuff in it... that makes the page state accounting
much lighter weight AND is not racy.

So I'm not exactly sure why such a patch as this is wanted now? Are there
any more xxx_page_state hotspots? (I admit to only looking at page faults,
page allocator, and page reclaim).


SUSE Labs, Novell Inc.
Send instant messages to your online friends

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-31 08:59    [W:0.090 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site