public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ahmed S. Darwish" <a.darwish@linutronix.de>
To: Dipen Patel <dipenp@nvidia.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Multi pthreaded RT application - mlock doubt
Date: Wed, 26 May 2021 10:31:11 +0200	[thread overview]
Message-ID: <YK4HT42yr02J1Gp1@lx-t490> (raw)
In-Reply-To: <95b1b0f8-4957-f9cb-0cf7-82c79d819c38@nvidia.com>

On Tue, May 25, 2021, Dipen Patel wrote:
...
> Original example shown in above link uses the
> prove_thread_stack_use_is_safe same way. I just extended it to call it
> locally and calculate it locally because of the mutli thread.

As I said, the example is wrong, and it is not authoritative. It is just
an old obsolete wiki that no one maintains anymore.

The same problem exists in the program you posted:

> static void prove_thread_stack_use_is_safe(int stacksize)
> {
>  	volatile char buffer[stacksize];
>  	int i;
>
>    	for (i = 0; i < stacksize; i += sysconf(_SC_PAGESIZE))
>    		buffer[i] = i;
> }
...
> static void *my_rt_thread(void *args)
> {
...
> 	int last_majflt = 0, last_minflt = 0;
...
>
>    	getrusage(RUSAGE_SELF, &usage);
>
>    	printf("[%d]Pagefaults, Major:%ld, Minor:%ld \n",pthread_self(),
>    	       usage.ru_majflt - last_majflt,
>    	       usage.ru_minflt - last_minflt);
>
> 	last_majflt = usage.ru_majflt;
>    	last_minflt = usage.ru_minflt;
>
>    	prove_thread_stack_use_is_safe(MY_STACK_SIZE);
>
> 	getrusage(RUSAGE_SELF, &usage);
>
>    	printf("[%d]After stack usage:Pagefaults, Major:%ld, Minor:%ld \n",pthread_self(),
>    	       usage.ru_majflt - last_majflt,
>    	       usage.ru_minflt - last_minflt);
>

You're just measuring the effect of stack prefaulting, which will
obviously generate page faults (as expected).

Given your original email in this thread, it seems you're conflicting
mlockall() with page faults.

mlockall() just forces physical memory pages ** already mapped through
the process address space ** to be memory-resident; i.e., not getting
swapped.  Even with MCL_CURRENT| MCL_FUTURE, mlockall() does not prevent
"demand paging" page faults: it only says that if your process got
allocated a phsyical memory page, it will not get swapped.

So, technically, the mlockall() effect will start only after
prove_thread_stack_use_is_safe() gets allocated real/physical memory
pages by its code which prefauls the stack.

The source of confusion, I guess, is that
prove_thread_stack_use_is_safe() is horribly named. In its first
invocation, it does not "prove" anything, it is actually the entity
prefaulting the thread stack.

Hope this helps,

--
Ahmed S. Darwish
Linutronix GmbH

  reply	other threads:[~2021-05-26  8:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  2:06 Multi pthreaded RT application - mlock doubt Dipen Patel
2021-05-25  3:08 ` Dipen Patel
2021-05-25  7:26 ` Ahmed S. Darwish
2021-05-25 22:24   ` Dipen Patel
2021-05-26  8:31     ` Ahmed S. Darwish [this message]
2021-05-26 10:26       ` John Ogness

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=YK4HT42yr02J1Gp1@lx-t490 \
    --to=a.darwish@linutronix.de \
    --cc=dipenp@nvidia.com \
    --cc=linux-rt-users@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox