lkml.org 
[lkml]   [1998]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject2.1.78: mm and networking questions...
Date
From
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


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.031 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site