From: Gabriele Monaco <gmonaco@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Mel Gorman <mgorman@suse.de>, Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 4/4] rseq/selftests: Add test for mm_cid compaction
Date: Fri, 13 Dec 2024 16:03:15 +0100 [thread overview]
Message-ID: <199437fe21ad5bb47ce81c560fbeb0495b5f9ce3.camel@redhat.com> (raw)
In-Reply-To: <d1e64ae2-9a16-44af-afca-a1940f27d4ef@efficios.com>
On Fri, 2024-12-13 at 09:29 -0500, Mathieu Desnoyers wrote:
> On 2024-12-13 04:54, Gabriele Monaco wrote:
> > A task in the kernel (task_mm_cid_work) runs somewhat periodically
> > to
> > compact the mm_cid for each process, this test tries to validate
> > that
> > it runs correctly and timely.
> >
> > + /*
> > + * We select one thread with high enough mm_cid to be the new
> > leader
> > + * all other threads (including the main thread) will terminate
> > + * After some time, the mm_cid of the only remaining thread should
> > + * converge to 0, if not, the test fails
> > + */
> > + if (curr_mm_cid > args->num_cpus / 2 &&
>
> I think we want curr_mm_cid >= args->num_cpus / 2 here,
> otherwise the case with 2 cpus would not match.
Right, good point.
> > + !pthread_mutex_trylock(&args->token)) {
> > + printf_verbose("cpu%d has %d and will be the new leader\n",
> > + sched_getcpu(), curr_mm_cid);
> > + for (i = 0; i < args->num_cpus; i++) {
> > + if (args->tinfo[i] == pthread_self())
> > + continue;
> > + ret = pthread_join(args->tinfo[i], NULL);
>
> We'd want a synchronization point to join the main thread. I'm not
> sure
> if the main thread is joinable.
>
> Perhaps we could try calling pthread_self() from the main thread, and
> store that in the main thread struct thread_args, and use it to join
> the main thread afterwards ?
> >
> > +void test_mm_cid_compaction(void)
> > +{
> > + for (i = 0, j = 0; i < CPU_SETSIZE && j < num_threads; i++) {
> > + if (CPU_ISSET(i, &affinity)) {
>
> Including the main thread, we end up creating nr_cpus + 1 threads.
> I suspect we want to take the main thread into account here, and
> create
> one less thread.
>
> We could use tinfo[0] to store the main thread info.
Good idea, that would get two birds with one stone.
I just forgot to pass it but it seems the main thread is perfectly
joinable (just checked), so that should work fairly easily.
>
> > + ret = pthread_create(&tinfo[j], NULL, thread_runner,
> > + &args);
> > + if (ret) {
> > + fprintf(stderr,
> > + "Error: failed to create thread(%d): %s\n",
> > + ret, strerror(ret));
> > + assert(ret == 0);
> > + }
> > + CPU_SET(i, &test_affinity);
> > + pthread_setaffinity_np(tinfo[j], sizeof(test_affinity),
> > + &test_affinity);
>
> It would be better that each thread set their own affinity when
> they start rather than having the main thread set each created thread
> affinity while they are already running. Otherwise it's racy and
> timing-dependent.
>
> And don't forget to set the main thread's affinity.
Sure, will do!
Thanks for the comments, working on V3.
Gabriele
next prev parent reply other threads:[~2024-12-13 15:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 9:54 [PATCH v2 0/4] sched: Move task_mm_cid_work to mm delayed work Gabriele Monaco
2024-12-13 9:54 ` [PATCH v2 1/4] " Gabriele Monaco
2024-12-13 14:14 ` Mathieu Desnoyers
2024-12-13 15:15 ` Gabriele Monaco
2024-12-13 9:54 ` [PATCH v2 2/4] sched: Remove mm_cid_next_scan as obsolete Gabriele Monaco
2024-12-13 14:01 ` Mathieu Desnoyers
2024-12-13 9:54 ` [PATCH v2 3/4] sched: Compact RSEQ concurrency IDs with reduced threads and affinity Gabriele Monaco
2024-12-13 14:05 ` Mathieu Desnoyers
2024-12-13 9:54 ` [PATCH v2 4/4] rseq/selftests: Add test for mm_cid compaction Gabriele Monaco
2024-12-13 14:29 ` Mathieu Desnoyers
2024-12-13 15:03 ` Gabriele Monaco [this message]
2024-12-13 11:31 ` [PATCH v2 0/4] sched: Move task_mm_cid_work to mm delayed work Gabriele Monaco
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=199437fe21ad5bb47ce81c560fbeb0495b5f9ce3.camel@redhat.com \
--to=gmonaco@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=vincent.guittot@linaro.org \
/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.