* REAL_PTRS_PER_PMD and TIF_32BIT
@ 2004-03-16 20:51 Ed L Cashin
2004-03-16 20:58 ` David S. Miller
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Ed L Cashin @ 2004-03-16 20:51 UTC (permalink / raw)
To: sparclinux
Hi. As far as I can tell, PTRS_PER_PMD will evaluate to 512 when a
32-bit binary in userland makes a system call or has a page fault,
since TIF_32BIT will be set in the thread flags.
I suppose that means that for every second-level page table associated
with a 32-bit binary's process, there are (2048 - 512) unused
pmd entries. Is that correct?
--
--Ed L Cashin | PGP public key:
ecashin@uga.edu | http://noserose.net/e/pgp/
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: REAL_PTRS_PER_PMD and TIF_32BIT
2004-03-16 20:51 REAL_PTRS_PER_PMD and TIF_32BIT Ed L Cashin
@ 2004-03-16 20:58 ` David S. Miller
2004-03-16 21:03 ` Ed L Cashin
2004-03-16 21:08 ` David S. Miller
2 siblings, 0 replies; 4+ messages in thread
From: David S. Miller @ 2004-03-16 20:58 UTC (permalink / raw)
To: sparclinux
On Tue, 16 Mar 2004 15:51:47 -0500
Ed L Cashin <ecashin@uga.edu> wrote:
> Hi. As far as I can tell, PTRS_PER_PMD will evaluate to 512 when a
> 32-bit binary in userland makes a system call or has a page fault,
> since TIF_32BIT will be set in the thread flags.
>
> I suppose that means that for every second-level page table associated
> with a 32-bit binary's process, there are (2048 - 512) unused
> pmd entries. Is that correct?
Yes, on sparc64, this is what effectively happens. We only need one
PMD to map the page tables for a 32-bit process on sparc64.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: REAL_PTRS_PER_PMD and TIF_32BIT
2004-03-16 20:51 REAL_PTRS_PER_PMD and TIF_32BIT Ed L Cashin
2004-03-16 20:58 ` David S. Miller
@ 2004-03-16 21:03 ` Ed L Cashin
2004-03-16 21:08 ` David S. Miller
2 siblings, 0 replies; 4+ messages in thread
From: Ed L Cashin @ 2004-03-16 21:03 UTC (permalink / raw)
To: sparclinux
"David S. Miller" <davem@redhat.com> writes:
> On Tue, 16 Mar 2004 15:51:47 -0500
> Ed L Cashin <ecashin@uga.edu> wrote:
>
>> Hi. As far as I can tell, PTRS_PER_PMD will evaluate to 512 when a
>> 32-bit binary in userland makes a system call or has a page fault,
>> since TIF_32BIT will be set in the thread flags.
>>
>> I suppose that means that for every second-level page table associated
>> with a 32-bit binary's process, there are (2048 - 512) unused
>> pmd entries. Is that correct?
>
> Yes, on sparc64, this is what effectively happens. We only need one
> PMD to map the page tables for a 32-bit process on sparc64.
I notice that in the kernel "pmd" is used to mean both the second
level page table, consisting of 2048 four-byte entries, and also as
shorthand for one of those entries. Did you intentionally use
all-caps for "PMD" to distinguish it from a second-level page table
entry?
--
--Ed L Cashin | PGP public key:
ecashin@uga.edu | http://noserose.net/e/pgp/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: REAL_PTRS_PER_PMD and TIF_32BIT
2004-03-16 20:51 REAL_PTRS_PER_PMD and TIF_32BIT Ed L Cashin
2004-03-16 20:58 ` David S. Miller
2004-03-16 21:03 ` Ed L Cashin
@ 2004-03-16 21:08 ` David S. Miller
2 siblings, 0 replies; 4+ messages in thread
From: David S. Miller @ 2004-03-16 21:08 UTC (permalink / raw)
To: sparclinux
On Tue, 16 Mar 2004 16:03:23 -0500
Ed L Cashin <ecashin@uga.edu> wrote:
> I notice that in the kernel "pmd" is used to mean both the second
> level page table, consisting of 2048 four-byte entries, and also as
> shorthand for one of those entries. Did you intentionally use
> all-caps for "PMD" to distinguish it from a second-level page table
> entry?
It's just sylistic for C code that CPP macros are capitalized,
that's all.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-03-16 21:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-16 20:51 REAL_PTRS_PER_PMD and TIF_32BIT Ed L Cashin
2004-03-16 20:58 ` David S. Miller
2004-03-16 21:03 ` Ed L Cashin
2004-03-16 21:08 ` David S. Miller
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.