* Dysthymicdolt@aol.com (Dysthymicdolt@aol.com) wrote:


let me first explain why such zeroed page is usually used. for example
in linux you have a 'zero_page' you allocate at boot, (of course
zero it) and set it read only. when some facility needs a zero page you
just give zero_page to it. obviously anyone can read it without a problem.

if somebody tries to write to that page an exception is raised. the os
exception handler, can then do the appropriate thing (for example allocate
new page, _copy or zero it_, modify page translation, flush it and allow
write to proceed.)

you suggest that reads from that page can be avoided (and also one could
save 1 page of main memory). i'd think saving 8 Kb of memory this way is not
that beneficial (if one would need to complicate hardware to do it).

you are absolutly right pointing out all the reads of zeroed page could be
avoided this way. i will now argue that most of the reads can be avoided
by os. judging by simulations i ran, most of the time you either
read a realtivly small chunk of zeroed page (a NULL pointer for example) or
have COW (copy on write) situation. it would seam to me that COW would
trigger dominant number of reads while copying zerod page. (and the 'small
read of zeros' is additionaly supressed by cache, asuming some locality)

os can detect COW scenario (described above) and instead of copying a
zeroed page just zero the new one (eliminating the reads all together). if
you look at the assembly for copying and compere it to
assembly for zeroing you can notice that even if hardware eliminated the
read, copy approach would still be slower.

i've done some (limited) analysis of runing linux and speeding it up
by optimizing string/memory operations. it turns out there is still a lot
of improvment possible in sofware and that trying to accelerate all such
operations with specialized hardware in my test scenario
wouldn't yield a big improvment...

however i may be persuaded otherwise if someone would show more detailed
analysis of some 'typical' situation. (by typical i mean
in general purpose os, or some not to specialized software. i'm sure a
very specific case can be found where such a hardware enchancment would
show significant performance gain.)

best regards,
p.

Would it be reasonable to provide a huge page physical address reserved as a read-only page of all zeroes? This would allow saving one page of PTEs for each Area of memory mapped but not modified and one page in the system that would otherwise be zeroed. This would also allow mapping the NULL pointer's page in a zero page and avoid a main memory read when the NULL pointer is referenced speculatively. (A DMA could also copy the read-only zero page to a regular memory page without having to read memory, though presumably the DMA hardware could be trivially extended to support repeated word copies.) Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040918/564cf6c3/attachment.htm

pheonix@opencores.org wrote:

Actually, it can be used for _any_ allocated page before it has been
written. One can thus map large allocations only using page table
memory

[snip]



The hardware complication could be as minimal as checking the 8 MSb
are equal zero [assuming 32-bit physical addresses and the use of a
huge zero page/zero Area].



I tend to agree that this would be of very limited usefulness. It is an idea
that popped into my head and wanted to share just in case. (BTW, NULL
pointer references might not be cached because such are somewhat
exceptional, like the terminating condition of a loop.)



Unless one uses a simplistic DMA to perform the copy. :-\

[snip]



The main advantage would seem to be in use with huge spaces of
zero-allocated memory that has not been written, in which case one
small page is saved for each huge page/Area. (The hardware
complexity seems likely to be small for such, but it would leave a
16MiB hole in the physical address space--eep!)

Paul A. Clayton more silly ideas are coming :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040920/4b9de664/attachment-0001.htm

* Dysthymicdolt@aol.com (Dysthymicdolt@aol.com) wrote:

well, the one exception would be any pages needed in
page fault handler path. (but that would be negliable.)

reading from allocated page before writting is almost certainly a bug,
so you expect a write to a newly allocated page. in
that case, why would one do a trick with page tables, just to trigger a
page fault shortly after (in kernel you usualy don't allocate memory areas
and not use them right away).

having said that, user space memory allocation is totaly
different. there you have to be carefull not to leak any information
from kernel (for example kernel frees a page, that is later given to
userspace). in that case you have to always zero a page. a commen trick is
to give userspace 'zero_page' and clear a page only when it tries to
be written to. (some user programs malloc huge chunks of memory that may
never be used. this way you can also defer allocation till the time it's
really needed)



my point was (not very clear though) that you either read alot from it and
is cached or you don't and it's not terrebly important performance wise.



i think that no idea is silly.

regards,
p.