On Fri, Apr 14, 2017 at 10:45:44AM +0200, Peter Zijlstra wrote: > On Thu, Apr 13, 2017 at 02:30:19PM -0700, Eric Dumazet wrote: > > On Thu, Apr 13, 2017 at 9:17 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > git log -S SLAB_DESTROY_BY_RCU > > > > Maybe, but "git log -S" is damn slow at least here. > > > > While "git grep" is _very_ fast > > All true. But in general we don't leave endless markers around like > this. > > For instance: > > /* the function formerly known as smp_mb__before_clear_bit() */ > > is not part of the kernel tree. People that used that thing out of tree > get to deal with it in whatever way they see fit. Sometimes we don't provide markers and sometimes we do: $ git grep synchronize_kernel Documentation/RCU/RTFP.txt:,Title="API change: synchronize_kernel() deprecated" Documentation/RCU/RTFP.txt: Jon Corbet describes deprecation of synchronize_kernel() kernel/rcu/tree.c: * synchronize_kernel() API. In contrast, synchronize_rcu() only Given that it has been more than a decade, I could easily see my way to removing this synchronize_kernel() tombstone in kernel/rcu/tree.c if people are annoyed by it. But thus far, no one has complained. So how long should we wait to remove the SLAB_DESTROY_BY_RCU tombstone? I can easily add an event to my calendar to remind me to remove it. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
