Messages in this thread | | | From | Shane Nay <> | Subject | VM Report was:Re: Break 2.4 VM in five easy steps | Date | Thu, 7 Jun 2001 16:29:17 -0700 |
| |
(VM report at Marcelo Tosatti's request. He has mentioned that rather than complaining about the VM that people mention what there experiences were. I have tried to do so in the way that he asked.)
> 1) Describe what you're running. (your workload)
A lot of daemons, all on a private network so there is no throughput load on them. About 13 rxvt's, freeamp actively playing music at all times, xemacs with 25 active buffers, a few instances of vi, opera, no "desktop env", just windowmaker. (Though I have a few KDE2 apps open, and one or two GTK based apps open, so lots of library code swapping in and out I imagine) Now what I've noticed lately is this, with 2.4.2 my machine would lock quite frequently when I was compiling code and had other apps that were allocing memory. With 2.4.5 I haven't had that behaviour, but I've been much lighter on my machine. (I was doing full toolchain builds with 2.4.2 when I had the real problems) But processes were still running when the machine would lock..., like the mp3 player was still playing I noticed one time. With 2.4.5 (not -ac) I haven't had any deadlocks, but the system seems very sluggish at acute moments . While doing absolutely nothing processor intensive (I've been loading up top and ps'ing with regularity when this happens, looking for kswapd going crazy), when I switch between workspaces the refresh is much more sluggish on occasion, like I can watch windows appear. Almost like a micro freeze really. (AMD T-Bird 1.333Mhz 256MB-DDR)
> 2) Describe what you're feeling. (eg "interactivity is crap when I run > this or that thing", etc)
Freeing memory takes *forever*, but I think that's a function of how I'm allocing in this polygon rendering routine I'm working on. Like literally sucks up vast numbers of cycles and makes picogui totally unusable. But I think this is unrelated to the kernel..., I think that's just because I haven't implemented re-use in memory structures for the polygon routine. (It's malloc/freeing massive numbers of small chunks of memory rather than doing it's own memory management, probably related to glibc memory organization)
Here's a vmstat line after a 8 days of uptime and before contrived mem tests: procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 3056 7856 121872 0 0 7 4 37 16 1 0 40
> If we need more info than that I'll request in private. > > Also send this reports to the linux-mm list, so other VM hackers can also > get those reports and we avoid traffic on lk.
> By performance you mean interactivity or throughput?
Interactivity. I don't have any throughput needs to speak of.
I just ran a barage of tests on my machine, and the smallest it would ever make the cache was 16M, it would prefer to kill processes rather than make the cache smaller than that.
Contrived stressor program: (pseudo code) fork(); fork(); fork(); fork(); //16 total processes for (i=0;i<n;i++) { ptr=malloc(1M) while(++m<ptrsize) ptr[m]='b'; sleep(2); } I would change n such that the total amount of memory was less than the amount of cache plus free memory. Running this put the entire system into chaos in short order. After it had killed off only one of the contrived memory hungry processes and at least two others (MP3 player and opera), the machine was slugish..., very slow to respond to any key input. It stayed in this near freeze state for about 20 seconds, after that it started to speed up to user input gradually. (Probably swapping code from disk into cache or something like that) It took about 5-10 minutes to come back "up to speed".
> Just do what I described above.
Done :).
Thanks, Shane Nay. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |