linux-kernel - Re: Question regarding Page Table size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0910062218350.18136@sister.anvils>
Date:	Tue, 6 Oct 2009 22:40:21 +0100 (BST)
From:	Hugh Dickins <hugh.dickins@...cali.co.uk>
To:	Ronny Egner <RonnyEgner@....de>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Question regarding Page Table size

On Tue, 6 Oct 2009, Ronny Egner wrote:

> Dear Kernel gurus,
> 
> i have a simple question but until now i did not find an answer. I beg your apologize if my question is misplaced.
> 
> 
> 
> So my question is:
> 
> "How much memory is needed in the kernel page table for a 
> process accessing a shared memory segment?"
> 
> 
> According to the information i have and found at the web the rule is:
> 
> 
> "4 Bytes per 4 KB referenced memory per process is allocated 
> in the page table"

That's often the case, but depends very much on your architecture
and its configuration.

4 bytes per 4kB is good for i386 (x86_32) architecture without PAE.

With PAE (Page Address Extension, originally a feature to allow the
32-bit Intel machine to support more than 4GB of physical memory,
nowadays often used on smaller machines for its NX no-execute flag),
the page table entry size is doubled to 8 bytes per 4kB page:
8 bytes per 4kB page applies also to x86_64 or amd64.

Some other architectures have 8kB or larger pages; 4 byte or 8 byte
page table entry per page will be common, but I'll bet there are
exceptions.

> 
> However i found one note saying because shared memory is 
> referenced 8 Bytes are needed:
> 
> 
> --- BEGIN QUOTE ---
> PageTables is memory to manage memory.
> 
> Each entry takes 4 bytes. Each 4 Kb of virtual (not swap) 
> memory requires one PTE to manage. This also counts for 
> shared memory, as with shared memory there is one physical 
> segment, but each process has its own virtual memory which 
> maps to this segment.
> 
> In Oracle’s case, assuming an SGA of 2 Gb, that is:
> 
> 524,288 pages * 8 bytes = 4 Mb per process
> 
> --- END QUOTE ---
> (Source: http://www.pythian.com/news/741/pythian-goodies-free-memory-swap-oracle-and-everything)
> 
> Until now i was not able to verify this information. So i am asking here
> for more information or perhaps a link.
> 
> 
> Where does the 8 byte in the calculation above come from?

I don't know, it doesn't explain; it seems like a misunderstanding.

It might be including, in addition to one set of page table entries,
the shmem/tmpfs tables allocated to hold swap entries in case the shared
memory pages get swapped out: that would add another 4 bytes on 32-bit
or 8 bytes on 64-bit; but there's only one set of those tables for the
shared memory object, it's not duplicated per process.

> 
> Taking the above example with a 2 GB shared memory segment the space 
> needed in the page table should be:
> 
>  524288 pages * 4 Bytes = 2 MB 
>      (for the process "owning" the shared memory segment)
> 
>  PLUS
> 
>  524288 pages * 4 Bytes = 2 MB 
>      (for *every* process referencing the shared memory 
>       segment assuming the fact the shared memory segment 
>       is referenced completely)

Yes, on i386 without PAE that's correct.  (I'd prefer not to
distinguish the "owner" and those sharing, just think of all
the processes using that shared memory segment.)

Hugh

> 
> Could anybody please give me a hint?
> 
> 
> Thanks in advance
> 
> -- 
> Ronny Egner
> -- 
> Ronny Egner
> RonnyEgner@....de