Re: [RFC V2] test_bit before clear files_struct bits

2015-02-10 Thread Linus Torvalds
On Tue, Feb 10, 2015 at 2:46 PM, Kirill A. Shutemov wrote: > > But I still fail to understand why my micro-benchmark is faster with > branch before store comparing to plain store. Very tight artificial loops like that tend to be horrible for performance analysis on modern cores, because you end u

Re: [RFC V2] test_bit before clear files_struct bits

2015-02-10 Thread Kirill A. Shutemov
On Tue, Feb 10, 2015 at 12:49:46PM -0800, Linus Torvalds wrote: > On Tue, Feb 10, 2015 at 12:22 PM, Andrew Morton > wrote: > > > > The patch is good but I'm still wondering if any CPUs can do this > > speedup for us. The CPU has to pull in the target word to modify the > > bit and what it *could*

Re: [RFC V2] test_bit before clear files_struct bits

2015-02-10 Thread Linus Torvalds
On Tue, Feb 10, 2015 at 12:22 PM, Andrew Morton wrote: > > The patch is good but I'm still wondering if any CPUs can do this > speedup for us. The CPU has to pull in the target word to modify the > bit and what it *could* do is to avoid dirtying the cacheline if it > sees that the bit is already

Re: [RFC V2] test_bit before clear files_struct bits

2015-02-10 Thread Andrew Morton
(cc Linus for CPU-fu) On Tue, 10 Feb 2015 15:11:37 +0800 "Wang, Yalin" wrote: > add test_bit() before clear close_on_exec and open_fds, > by trace __clear_bit(), these 2 place are false in most times, > we test it so that we don't need clear_bit, and we can win > in most time. > > ... > > ---

[RFC V2] test_bit before clear files_struct bits

2015-02-09 Thread Wang, Yalin
add test_bit() before clear close_on_exec and open_fds, by trace __clear_bit(), these 2 place are false in most times, we test it so that we don't need clear_bit, and we can win in most time. Signed-off-by: Yalin Wang --- fs/file.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff