* [Xenomai-core] User space stack pre-faulting
@ 2011-06-22 9:26 Jan Kiszka
2011-06-22 10:36 ` Gilles Chanteperdrix
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2011-06-22 9:26 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai core
Hi Gilles,
do you remember reasons for only pre-faulting the main thread's stack?
The desire to avoid wasting resources by forcing all stacks into memory?
I've the requirement on my table to provide a generic solution of all
shadow threads. I think this should be possible using pthread_getattr_np
and walking the stack page-wise, but I may miss some pitfall.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] User space stack pre-faulting
2011-06-22 9:26 [Xenomai-core] User space stack pre-faulting Jan Kiszka
@ 2011-06-22 10:36 ` Gilles Chanteperdrix
2011-06-22 10:55 ` Jan Kiszka
0 siblings, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-22 10:36 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
On 06/22/2011 11:26 AM, Jan Kiszka wrote:
> Hi Gilles,
>
> do you remember reasons for only pre-faulting the main thread's stack?
> The desire to avoid wasting resources by forcing all stacks into memory?
>
> I've the requirement on my table to provide a generic solution of all
> shadow threads. I think this should be possible using pthread_getattr_np
> and walking the stack page-wise, but I may miss some pitfall.
Last time I checked, only the main thread stack was mapped on demand.
Other threads have mmaped stacks, which are made present by mlockall,
so, do not need faulting.
--
Gilles.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] User space stack pre-faulting
2011-06-22 10:36 ` Gilles Chanteperdrix
@ 2011-06-22 10:55 ` Jan Kiszka
2011-06-22 10:56 ` Gilles Chanteperdrix
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2011-06-22 10:55 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai core
On 2011-06-22 12:36, Gilles Chanteperdrix wrote:
> On 06/22/2011 11:26 AM, Jan Kiszka wrote:
>> Hi Gilles,
>>
>> do you remember reasons for only pre-faulting the main thread's stack?
>> The desire to avoid wasting resources by forcing all stacks into memory?
>>
>> I've the requirement on my table to provide a generic solution of all
>> shadow threads. I think this should be possible using pthread_getattr_np
>> and walking the stack page-wise, but I may miss some pitfall.
>
> Last time I checked, only the main thread stack was mapped on demand.
> Other threads have mmaped stacks, which are made present by mlockall,
> so, do not need faulting.
That's definitely not the case in general. Customer has just confirmed
that pre-faulting thread stacks avoids first-access domain switches.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] User space stack pre-faulting
2011-06-22 10:55 ` Jan Kiszka
@ 2011-06-22 10:56 ` Gilles Chanteperdrix
2011-06-22 12:26 ` Jan Kiszka
0 siblings, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2011-06-22 10:56 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
On 06/22/2011 12:55 PM, Jan Kiszka wrote:
> On 2011-06-22 12:36, Gilles Chanteperdrix wrote:
>> On 06/22/2011 11:26 AM, Jan Kiszka wrote:
>>> Hi Gilles,
>>>
>>> do you remember reasons for only pre-faulting the main thread's stack?
>>> The desire to avoid wasting resources by forcing all stacks into memory?
>>>
>>> I've the requirement on my table to provide a generic solution of all
>>> shadow threads. I think this should be possible using pthread_getattr_np
>>> and walking the stack page-wise, but I may miss some pitfall.
>>
>> Last time I checked, only the main thread stack was mapped on demand.
>> Other threads have mmaped stacks, which are made present by mlockall,
>> so, do not need faulting.
>
> That's definitely not the case in general. Customer has just confirmed
> that pre-faulting thread stacks avoids first-access domain switches.
self-contained test case please.
>
> Jan
>
--
Gilles.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] User space stack pre-faulting
2011-06-22 10:56 ` Gilles Chanteperdrix
@ 2011-06-22 12:26 ` Jan Kiszka
0 siblings, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2011-06-22 12:26 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai core
On 2011-06-22 12:56, Gilles Chanteperdrix wrote:
> On 06/22/2011 12:55 PM, Jan Kiszka wrote:
>> On 2011-06-22 12:36, Gilles Chanteperdrix wrote:
>>> On 06/22/2011 11:26 AM, Jan Kiszka wrote:
>>>> Hi Gilles,
>>>>
>>>> do you remember reasons for only pre-faulting the main thread's stack?
>>>> The desire to avoid wasting resources by forcing all stacks into memory?
>>>>
>>>> I've the requirement on my table to provide a generic solution of all
>>>> shadow threads. I think this should be possible using pthread_getattr_np
>>>> and walking the stack page-wise, but I may miss some pitfall.
>>>
>>> Last time I checked, only the main thread stack was mapped on demand.
>>> Other threads have mmaped stacks, which are made present by mlockall,
>>> so, do not need faulting.
>>
>> That's definitely not the case in general. Customer has just confirmed
>> that pre-faulting thread stacks avoids first-access domain switches.
>
> self-contained test case please.
Yes, will check this. Currently distracted again by a higher prio oops :-/.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-06-22 12:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-22 9:26 [Xenomai-core] User space stack pre-faulting Jan Kiszka
2011-06-22 10:36 ` Gilles Chanteperdrix
2011-06-22 10:55 ` Jan Kiszka
2011-06-22 10:56 ` Gilles Chanteperdrix
2011-06-22 12:26 ` Jan Kiszka
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.