Messages in this thread | | | Subject | 2.1.78: mm and networking questions... | Date | Wed, 7 Jan 1998 20:58:24 -0600 (CST) | From | kwrohrer@enteract ... |
| |
I've got a few questions I can't readily glean from the code or the (obsolete) KHG...
(1) There's just one "struct page" per physical page? And there's an array "mem_map" of these, indexed redundantly by MAP_NR(address) and by struct page::map_nr?
(2) What on earth is "mem_map_t" doing, and why should this alias for "struct page" exist?
(3) Would performance suffer horribly if the struct page were to have a more even (14 or 16) number of words in it, or would we get back performance by making the cache line boundaries fall in the right places?
(4) Similarly to (1) I take it there's exactly one struct mm_struct per struct task_struct, and each of the struct vm_area_struct *mmap points to a chain of vma's unique to the task?
(5) When we start to swap a page out to disk, if the process wants to write to that page, what happens? I can't find anything to prevent the access, nor can I find anything that would notice such an access, until the disk I/O completes and the page gets replaced or hits the swap cache...
(6) Similarly, if I were to pte_mkold some "innocent" pages to encourage them to be copied out to disk, would there be a major penalty (besides perhaps a wasted disk write) involved if they were still in frequent use? If I'm right about (1) then artificial aging should encourage free areas of the desired size, without the need for a reverse page table...
(7) If we had a reverse page table, and could walk physical memory in search of stuff to swap out, might that lead to better balancing between different sorts of pages (e.g. process vs. buffer cache)? (Not to mention, a bit faster?)
(8) As reported by shift-ScrollLock, should the "IP fragment buffer size" really be 0 all the time? The machine's networks are all point- to-point with an always-defragment firewall, so it makes some sense...but alas all the unassembled fragment buffers in the world don't make for a single skbuff to stick them in.
(9) Does paging in recent (2.1.>50 or so) kernels seem a lot slower than in the good old days? My swap disk can manage several megabytes per second, sustained, but e.g. the backdrop in X pages in at around an inch per second at times. Is /proc/sys/vm/freepages set too low (especially the latter values)? Or is there some other condition that's limiting page-in speed?
Most (1-6) of those questions I think I already know the answers to, I'm just looking for confirmation (and perhaps elaborating details) so that we can stick this whole thread in the KHG and nobody will have to go through what I've had to go through until at least 2.1.79 or 2.3.1... The latter three are more theoretical/philosophical questions...
Keith
| |