Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2 Aug 2019 16:18:40 +0800 Michal Hocko wrote:
>
> [Hillf, your email client or workflow mangles emails. In this case you
> are seem to be reusing the message id from the email you are replying to
> which confuses my email client to assume your email is a duplicate.]

[Hi Michal, I sent the previous mail with

	Message-id: <7EE30F16-A90B-47DC-A065-3C21881CD1CC@xxxxxxxxx>

using git send-email after quitting vi. That tag is removed from this
message and get me informed if it makes your mail client happy.]
>
> Huh, what? You are effectively saying that we should fail the charge
> when the requested nr_pages would fit in. This doesn't make much sense
> to me. What are you trying to achive here?

The report looks like the result of a tight loop.
I want to break it and make the end result of do_page_fault unsuccessful
if nr_retries rounds of page reclaiming fail to get work done. What made
me a bit over stretched is how to determine if the chargee is a memhog
in memcg's vocabulary.
What I prefer here is that do_page_fault succeeds, even if the chargee
exhausts its memory quota/budget granted, as long as more than nr_pages
can be reclaimed _within_ nr_retries rounds. IOW the deadline for memhog
is nr_retries, and no more.

Thanks
Hillf




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux