On 10.01.2019 22:19, Shakeel Butt wrote: > On Thu, Jan 10, 2019 at 1:46 AM Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote: >> >> Hi, Shakeel, >> >> On 09.01.2019 20:37, Shakeel Butt wrote: >>> Hi Kirill, >>> >>> On Wed, Jan 9, 2019 at 4:20 AM Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> wrote: >>>> >>>> On nodes without memory overcommit, it's common a situation, >>>> when memcg exceeds its limit and pages from pagecache are >>>> shrinked on reclaim, while node has a lot of free memory. >>>> Further access to the pages requires real device IO, while >>>> IO causes time delays, worse powerusage, worse throughput >>>> for other users of the device, etc. >>>> >>>> Cleancache is not a good solution for this problem, since >>>> it implies copying of page on every cleancache_put_page() >>>> and cleancache_get_page(). Also, it requires introduction >>>> of internal per-cleancache_ops data structures to manage >>>> cached pages and their inodes relationships, which again >>>> introduces overhead. >>>> >>>> This patchset introduces another solution. It introduces >>>> a new scheme for evicting memcg pages: >>>> >>>> 1)__remove_mapping() uncharges unmapped page memcg >>>> and leaves page in pagecache on memcg reclaim; >>>> >>>> 2)putback_lru_page() places page into root_mem_cgroup >>>> list, since its memcg is NULL. Page may be evicted >>>> on global reclaim (and this will be easily, as >>>> page is not mapped, so shrinker will shrink it >>>> with 100% probability of success); >>>> >>>> 3)pagecache_get_page() charges page into memcg of >>>> a task, which takes it first. >>>> >>> >>> From what I understand from the proposal, on memcg reclaim, the file >>> pages are uncharged but kept in the memory and if they are accessed >>> again (either through mmap or syscall), they will be charged again but >>> to the requesting memcg. Also it is assumed that the global reclaim of >>> such uncharged file pages is very fast and deterministic. Is that >>> right? >> >> Yes, this was my assumption. But Michal, Josef and Johannes pointed a diving >> into reclaim in general is not fast. So, maybe we need some more creativity >> here to minimize the effect of this diving.. >> > > I kind of disagree that this patchset is breaking the API semantics as > the charged memory of a memcg will never go over max/limit_in_bytes. > However the concern I have is the performance isolation. The > performance of a pagecache heavy job with a private mount can be > impacted by other jobs running on the system. This might be fine for > some customers but not for Google. One use-case I can tell is the > auto-tuner which adjusts the limits of the jobs based on their > performance and history. So, to make the auto-tuning deterministic we > have to disable the proposed optimization for the jobs with > auto-tuning enabled. Beside that there are internal non-auto-tuned > customers who prefer deterministic performance. > > Also I am a bit skeptical that the allocation from the pool of such > (clean unmapped uncharged) file pages can be made as efficient as > fastpath of page allocator. Even if these pages are stored in a > separate list instead of root's LRU, on allocation, the pages need to > be unlinked from their mapping and has to be cleared. I'd said, we move this unlinking from one place to another, so the unlinking itself does not introduce more pressure on node. The difference to current behavior is 1)we need to get through all shrinker functions once again, 2)this forces caller to do global reclaim and iterate all memcgs. But it looks like these two things may be solved in some way. > BTW does this optimization have any impact on workingset mechanism? I won't say exactly, but since pages are unmapped, we should not call any workingset handlers, so I don't know what we may break there. Kirill
