Messages in this thread | | | Date | Wed, 14 Oct 2020 12:19:04 +0200 | From | Jan Kara <> | Subject | Re: [mm/writeback] 8d92890bd6: will-it-scale.per_process_ops -15.3% regression |
| |
On Wed 14-10-20 16:47:06, kernel test robot wrote: > Greeting, > > FYI, we noticed a -15.3% regression of will-it-scale.per_process_ops due > to commit: > > commit: 8d92890bd6b8502d6aee4b37430ae6444ade7a8c ("mm/writeback: discard > NR_UNSTABLE_NFS, use NR_WRITEBACK instead") > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
Thanks for report but it doesn't quite make sense to me. If we omit reporting & NFS changes in that commit (which is code not excercised by this benchmark), what remains are changes like:
nr_pages += node_page_state(pgdat, NR_FILE_DIRTY); - nr_pages += node_page_state(pgdat, NR_UNSTABLE_NFS); nr_pages += node_page_state(pgdat, NR_WRITEBACK); ... - nr_reclaimable = global_node_page_state(NR_FILE_DIRTY) + - global_node_page_state(NR_UNSTABLE_NFS); + nr_reclaimable = global_node_page_state(NR_FILE_DIRTY); ... - gdtc->dirty = global_node_page_state(NR_FILE_DIRTY) + - global_node_page_state(NR_UNSTABLE_NFS); + gdtc->dirty = global_node_page_state(NR_FILE_DIRTY);
So if there's any negative performance impact of these changes, they're likely due to code alignment changes or something like that... So I don't think there's much to do here since optimal code alignment is highly specific to a particular CPU etc.
Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
| |