On 15.06.23 13:15, 贺中坤 wrote:
On Thu, Jun 15, 2023 at 5:27 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
Interesting. When looking at possible ways to achieve that in a clean
way, my understanding was that the page might not always be accounted to
a memcg (e.g., simply some buffer?). Besides the swap->zram case I was
thinking about other fs->zram case, or just a straight read/write to the
zram device.
The easiest way to see where that goes wrong I think is
zram_bvec_write_partial(), where we simply allocate a temporary page.
Either I am missing something important, or this only works in some
special cases.
I came to the conclusion that the only reasonable way is to assign a
complete zram device to a single cgroup and have all memory accounted to
that cgroup. Does also not solve all use cases (especially the
swap->zram case that might be better offjust using zswap?) but at least
the memory gets accounted in a more predictable way.
Happy to learn more.
--
Cheers,
David / dhildenb
Hi david, thanks for your reply. This should be my mistake, I didn't
describe the
problem clearly.
The reason for the problem is not the temporary page allocated at the beginning
of zram_bvec_write_partial() and released at the end,but the compressed memory
allocated by zs_malloc() in zram_write_page().
So, it may not meet the need to assign a complete zram device to a
single cgroup.
we need to charge the compressed memory to the original page's memory cgroup,
which is not charged so far.
Yes, but my point is that there are cases where the pages you get are
not charged. zram_bvec_write_partial() is just one such example that
highlights the issue.
--
Cheers,
David / dhildenb
