* Jan Kara <jack@xxxxxxx> wrote: > > > > With an exit microbenchmark that creates a large number of threads, > > > > attachs many inodes to them and then exits. The runtimes of that > > > > microbenchmark with 1000 threads before and after the patch on a 4-socket > > > > Intel E7-4820 v3 system (40 cores, 80 threads) were as follows: > > > > > > > > Kernel Elapsed Time System Time > > > > ------ ------------ ----------- > > > > Vanilla 4.5-rc4 65.29s 82m14s > > > > Patched 4.5-rc4 22.81s 23m03s > > > > > > > > Before the patch, spinlock contention at the inode_sb_list_add() function > > > > at the startup phase and the inode_sb_list_del() function at the exit > > > > phase were about 79% and 93% of total CPU time respectively (as measured > > > > by perf). After the patch, the percpu_list_add() function consumed only > > > > about 0.04% of CPU time at startup phase. The percpu_list_del() function > > > > consumed about 0.4% of CPU time at exit phase. There were still some > > > > spinlock contention, but they happened elsewhere. > > > > > > While looking through this patch, I have noticed that the > > > list_for_each_entry_safe() iterations in evict_inodes() and > > > invalidate_inodes() are actually unnecessary. So if you first apply the > > > attached patch, you don't have to implement safe iteration variants at all. > > > > > > As a second comment, I'd note that this patch grows struct inode by 1 > > > pointer. It is probably acceptable for large machines given the speedup but > > > it should be noted in the changelog. Furthermore for UP or even small SMP > > > systems this is IMHO undesired bloat since the speedup won't be noticeable. > > > > > > So for these small systems it would be good if per-cpu list magic would just > > > fall back to single linked list with a spinlock. Do you think that is > > > reasonably doable? > > > > Even many 'small' systems tend to be SMP these days. > > Yes, I know. But my tablet with 4 ARM cores is unlikely to benefit from this > change either. [...] I'm not sure about that at all, the above numbers are showing a 3x-4x speedup in system time, which ought to be noticeable on smaller SMP systems as well. Waiman, could you please post the microbenchmark? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
