All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 5/5] cgroup: Add memcontrol02
Date: Wed, 05 Jan 2022 05:12:52 +0000	[thread overview]
Message-ID: <87wnjen4p5.fsf@suse.de> (raw)
In-Reply-To: <871r1no5kd.fsf@suse.de>

Hello,

Richard Palethorpe <rpalethorpe@suse.de> writes:

> Hello,
>
> Cyril Hrubis <chrubis@suse.cz> writes:
>
>>> + *
>>> + * [Description]
>>> + *
>>> + * Conversion of second kself test in cgroup/test_memcontrol.c.
>>> + *
>>> + * Original description:
>>> + * "This test creates a memory cgroup, allocates some anonymous memory
>>> + * and some pagecache and check memory.current and some memory.stat
>>> + * values."
>>> + *
>>> + * Note that the V1 rss and cache counters were renamed to anon and
>>> + * file in V2. Besides error reporting, this test differs from the
>>> + * kselftest in the following ways:
>>> + *
>>> + * . It supports V1.
>>> + * . It writes instead of reads to fill the page cache. Because no
>>> + *   pages were allocated on tmpfs.
>>
>> Shouldn't we actually run the test both for read/write and skip the read
>> part of tmpfs?
>>
>> Well I guess that the pages are put into the page cache the same way
>> regardless if they came from userspace write or as a request for data to
>> be read from the disk, so probably not I guess.
>
> I reckon there are a lot of ways to fill the page cache from
> userland. mmap and madvise also come to mind. I don't know how many ways
> there are to get/allocate a page from the page cache internally. I guess
> it's possible to circumvent the accountancy.
>
> I think for now just writing is good enough. This doesn't appear to be
> the only test which measures the page cache. So I think we should look
> at what the other tests do first. 
>
>>
>>> + * . It runs on most filesystems available
>>> + * . On EXFAT and extN we change the margine of error between all and file
>>                                            ^
>> 					   margin
>>> + *   memory to 50%. Because these allocate non-page-cache memory during writes.
>>> + */
>>> +#define _GNU_SOURCE
>>> +
>>> +#include <stdlib.h>
>>> +#include <stdio.h>
>>
>> Do we really need stdio here?
>
> Sorry, nope.
>

Actually it is needed otherwise BUFSIZ is undefined...

-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

      reply	other threads:[~2022-01-05  5:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 12:20 [LTP] [PATCH v3 1/5] API/cgroup: Add safe_cgroup_lines_scanf Richard Palethorpe via ltp
2022-01-04 12:20 ` [LTP] [PATCH v3 2/5] API/cgroup: Add memory.stat Richard Palethorpe via ltp
2022-01-04 12:20 ` [LTP] [PATCH v3 3/5] API/fs: Add exfat magic Richard Palethorpe via ltp
2022-01-04 14:20   ` Cyril Hrubis
2022-01-04 12:20 ` [LTP] [PATCH v3 4/5] API: Add TST_EXP_EXPR macro Richard Palethorpe via ltp
2022-01-04 14:25   ` Cyril Hrubis
2022-01-04 12:20 ` [LTP] [PATCH v3 5/5] cgroup: Add memcontrol02 Richard Palethorpe via ltp
2022-01-04 15:02   ` Cyril Hrubis
2022-01-04 15:26     ` Richard Palethorpe
2022-01-05  5:12       ` Richard Palethorpe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnjen4p5.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.