[CC Kamezawa]
On Fri 23-02-18 10:47:16, Daniel Colascione wrote:
> On Fri, Feb 23, 2018 at 9:50 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> > On Fri 23-02-18 08:34:19, Daniel Colascione wrote:
[...]
> >> Maybe I'm wrong, but I feel like taking page faults will touch per-mm
> >> data structures anyway, so one additional atomic update on the mm
> >> shouldn't hurt all that much.
> >
> > I wouldn't be oppposed to remove it completely if it is not measureable.
>
> Just deleting SPLIT_RSS_COUNTING is certainly my preferred option. I
> didn't see any benchmarks accompanying the inclusion of the mechanism
> in the first place.
You are right that 34e55232e59f ("mm: avoid false sharing of
mm_counter") was rather poor on the testing and convincing numbers. It
is not really clear where
[before]
4.5 cache-miss/faults
[after]
4.0 cache-miss/faults
come from.
> How would you suggest verifying that we can safely
> delete it?
Heavy parallel page fault test but you would have to be careful to not
measure the page allocator overhead.
> I *think* it would have the greatest benefit on very large
> systems with lots of tasks sharing and mm, each taking page faults
> often, but I don't have any such large machines.
The more I think about it the more I am convinced that we should simply
disable SPLIT_RSS_COUNTING by default or even remove the code
altogether.
Kamezawa, did you or anybody else have any specific workload which
benefited from this change or it was merely "this sounds like a good
optimization" thingy?
--
Michal Hocko
SUSE Labs
--
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>
