sorry, just realize never complete my explanation....:-). the reason is because if there exists a max RSS, then there may already be swapout operation occuring in your process A running alone by itself, as it can never allocate more than the max rss. so multiple process can have max rss reached at the same time......hm.....sound quite reasonable in terms of resources allocation right? On Mon, Sep 1, 2008 at 8:27 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > Not sure if I am right or not, but the answer to your question is > something called "maximum RSS". U can learn this through several > experiments (my physical mem is 1G): > > a. write a C program to malloc 1MB. memset the space with > something. "ps aux" to see the total RSS for this process. RSS is > the physical pages memory that will be allocated for your C program. > After malloc() u can see that the RSS is a very small nos. But after > memset() it immediately become a large number. Alternatively, write > a loop to update byte by byte, and then u can see the growth of RSS > from small to large number,. > > b. Change 1MB to 10MB, and u can see that the RSS is increased. > > c. Change it to 90MB, and u can see that there is not much increased in RSS. > > "ps" give u the total RSS pages, but if u want to see the specific > breakdown of the physical pages per segment of memory, use > /proc/pid/smaps: > > > root 24470 0.0 1.0 93664 10568 pts/3 S 08:22 0:00 > \_ a.out > > 08049000-0804a000 rwxp 00000000 08:01 2184953 /root/a.out > Size: 4 kB > Rss: 4 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 4 kB > b23df000-b7de1000 rwxp b23df000 00:00 0 ======================>heap > area for malloc(). > Size: 92168 kB > Rss: 10248 kB=========> not much increased when jumping > from 10MB to 90MB memory allocation. > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 10248 kB > b7de1000-b7f1c000 r-xp 00000000 08:01 766693 /lib/tls/i686/cmov/libc-2.5.so > Size: 1260 kB > Rss: 168 kB > Shared_Clean: 168 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 0 kB > > > On Fri, Aug 29, 2008 at 9:33 AM, Arn <cse.syslab@xxxxxxxxx> wrote: >> Hi, >> >> I'm using a 2.6.26 kernel on an AMD64 machine. Im running some timing >> experiments on the Linux swapping system. >> My system has 2GB of RAM but I boot linux with mem=1GB. >> >> There's is some behavior happening which I don't understand and I'm >> hoping someone can explain it to me. >> >> Here is what my experimental (simple) programs do. in sequence : >> >> 1) Process A grabs a lot of memory (calloc). It takes about 90% of memory >> 2) Process A does some reads/writes to all its allocated memory >> 3) Start process B. This also grabs a lot of memory (calloc). >> 4) Process B writes to all its allocated memory >> 5) OS swaps out Process A pages (to swap device) to make room for B >> 6) Process A does a timed read of all its pages. >> >> In this case I was expecting it to take a while to do the timed read >> since all its pages have been swapped to >> disk. However this is not the case. It takes the same amount of time >> as when I don't run Process B. This is >> counter to my understanding of how it should work. >> >> If I replace step 6) above with : >> >> 6) Process A does a timed write of all its pages >> >> Then I see the expected behavior which is that it takes a long time >> because all its pages are swapped in first. >> Why is there this discrepancy between timed reads and writes ? >> At first I thought it may be because AMD64 has a tagged cache and >> tagged TLB which causes this behaviour >> but I'm not really sure. Does anyone have an idea ? >> >> Thanks >> arn >> >> -- >> To unsubscribe from this list: send an email with >> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx >> Please read the FAQ at http://kernelnewbies.org/FAQ >> >> > > > > -- > Regards, > Peter Teoh > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
