Hi Tejun,
On Fri, Jul 26, 2024 at 4:22 PM Tejun Heo wrote:
>
> Hello, David.
>
> On Tue, Jul 23, 2024 at 07:31:48PM -0400, David Finkel wrote:
> ...
> > + A write of the string "reset" to this file resets it to the
> > + current memory usage for subsequent reads through the same
> > +
Hello, David.
On Tue, Jul 23, 2024 at 07:31:48PM -0400, David Finkel wrote:
...
> + A write of the string "reset" to this file resets it to the
> + current memory usage for subsequent reads through the same
> + file descriptor.
> + Attempts to write any other non-empty string will
On Wed, Jul 24, 2024 at 7:49 AM Johannes Weiner wrote:
>
> On Tue, Jul 23, 2024 at 09:55:19PM -0400, Waiman Long wrote:
> > Could you use the "-v " option of git-format-patch to add a version
> > number to the patch title? Without that, it can be confusing as to
> > whether the patch is new or a r
On Tue, Jul 23, 2024 at 09:55:19PM -0400, Waiman Long wrote:
> Could you use the "-v " option of git-format-patch to add a version
> number to the patch title? Without that, it can be confusing as to
> whether the patch is new or a resend of the previous one.
+1
> > @@ -775,6 +775,11 @@ struct
On 7/23/24 19:31, David Finkel wrote:
Other mechanisms for querying the peak memory usage of either a process
or v1 memory cgroup allow for resetting the high watermark. Restore
parity with those mechanisms, but with a less racy API.
For example:
- Any write to memory.max_usage_in_bytes in a c
Other mechanisms for querying the peak memory usage of either a process
or v1 memory cgroup allow for resetting the high watermark. Restore
parity with those mechanisms, but with a less racy API.
For example:
- Any write to memory.max_usage_in_bytes in a cgroup v1 mount resets
the high waterma
Hi Johannes,
Thanks for the thorough review!
I'll send a rebased version addressing your comments in a moment.
On Tue, Jul 23, 2024 at 10:29 AM Johannes Weiner wrote:
>
> Hi David,
>
> thanks for pursuing this! A couple of comments below.
>
> On Mon, Jul 22, 2024 at 07:55:53PM -0400, David Fink
Hi David,
thanks for pursuing this! A couple of comments below.
On Mon, Jul 22, 2024 at 07:55:53PM -0400, David Finkel wrote:
> @@ -1322,11 +1322,16 @@ PAGE_SIZE multiple when read back.
> reclaim induced by memory.reclaim.
>
>memory.peak
> - A read-only single value file which ex
Other mechanisms for querying the peak memory usage of either a process
or v1 memory cgroup allow for resetting the high watermark. Restore
parity with those mechanisms, but with a less racy API.
For example:
- Any write to memory.max_usage_in_bytes in a cgroup v1 mount resets
the high waterma
