* garbage collecting! How to expand physical-mem used?
@ 2004-07-27 5:29 David Combs
2004-07-27 12:28 ` Pascal Bourguignon
0 siblings, 1 reply; 2+ messages in thread
From: David Combs @ 2004-07-27 5:29 UTC (permalink / raw)
garbage collecting! How to expand physical-mem used?
My god, does my emacs thrash! (I have it typing out whenever a
gc happens).
(I keep a *huge* *Buffer List*, .emacs.desktop, etc)
Anyway, while doing an ediff-buffers, the thrashing was really
heavy. I wondered if I perhaps had lots of physical-memory
left unused on the computer -- so, while in one window ("frame",
I guess) running emacs thrashing, in another dtterm I did a
vmstat 2, and here it is.
Looks to me that although emacs is thrashing all to beat hell,
the computer itself is not. (Do I read the vmstat stuff correctly?)
If so, the questions is, how to get emacs to grab a larger working
set (or whatever it's called -- more physical memory).
Any ideas?
Thanks!
Here's the vmstat:
kthr memory page disk faults cpu
...
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 405 236 1 0 99
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 281 216 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 284 226 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 403 224 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 281 216 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 388 238 1 0 99
1 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 405 475 246 3 0 97
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr dd dd f0 s2 in sy cs us sy id
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 297 225 0 0 100
0 0 0 902088 135560 8 102 0 0 0 0 0 0 0 0 0 410 762 327 16 5 79
0 0 0 902088 135560 8 100 0 0 0 0 0 0 0 0 0 407 720 307 15 5 79
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 405 492 226 95 5 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 405 487 255 41 2 57
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 436 235 0 5 94
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 285 214 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 301 225 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 276 217 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 282 211 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 280 214 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 282 213 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 367 222 1 0 99
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 405 517 258 3 0 97
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 304 216 0 0 100
0 0 0 902088 135560 4 62 0 0 0 0 0 0 0 0 0 406 615 279 51 5 44
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 405 408 223 42 3 54
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 407 583 303 15 0 85
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 406 732 269 64 5 31
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr dd dd f0 s2 in sy cs us sy id
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 420 238 78 0 22
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 424 254 6 4 90
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 407 433 265 6 0 94
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 407 592 310 11 0 89
0 0 0 902088 135560 4 62 0 0 0 0 0 0 0 0 0 404 464 230 86 7 6
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 353 208 100 0 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 336 220 100 0 0
0 0 0 902088 135560 4 53 0 0 0 0 0 0 0 0 0 406 588 279 25 3 72
0 0 0 902088 135560 8 115 0 0 0 0 0 0 0 0 0 406 616 269 50 8 42
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 406 580 253 71 4 25
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 447 247 77 0 23
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 407 597 263 49 2 48
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 336 204 99 1 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 405 545 284 42 1 57
0 0 0 902088 135560 4 61 0 0 0 0 0 0 0 0 0 407 637 276 59 3 37
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 331 206 100 0 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 327 212 96 4 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 402 324 204 100 0 0
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 347 221 100 0 0
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr dd dd f0 s2 in sy cs us sy id
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 393 235 43 1 56
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 407 495 241 3 0 97
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 437 226 0 0 100
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 405 413 229 1 0 99
0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 403 307 236 0 0 100
Thanks!
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: garbage collecting! How to expand physical-mem used?
2004-07-27 5:29 garbage collecting! How to expand physical-mem used? David Combs
@ 2004-07-27 12:28 ` Pascal Bourguignon
0 siblings, 0 replies; 2+ messages in thread
From: Pascal Bourguignon @ 2004-07-27 12:28 UTC (permalink / raw)
dkcombs@panix.com (David Combs) writes:
> garbage collecting! How to expand physical-mem used?
>
>
>
>
> My god, does my emacs thrash! (I have it typing out whenever a
> gc happens).
>
> (I keep a *huge* *Buffer List*, .emacs.desktop, etc)
>
> Anyway, while doing an ediff-buffers, the thrashing was really
> heavy. I wondered if I perhaps had lots of physical-memory
> left unused on the computer -- so, while in one window ("frame",
> I guess) running emacs thrashing, in another dtterm I did a
> vmstat 2, and here it is.
Oh! You're not using Linux... I really feel that Linux vm is much
much better than mach or *bsd vm!
> Looks to me that although emacs is thrashing all to beat hell,
> the computer itself is not. (Do I read the vmstat stuff correctly?)
>
> If so, the questions is, how to get emacs to grab a larger working
> set (or whatever it's called -- more physical memory).
>
> Any ideas?
Well, I don't know about mach or *bsd, but on Linux you could wire
pages for emacs (you'd need to patch emacs' sources, and at least
start it suid root).
Anyway, that would work against you given the good job the OS does.
> Here's the vmstat:
> kthr memory page disk faults cpu
> 0 0 0 902088 135560 0 0 0 0 0 0 0 0 0 0 0 404 405 236 1 0 99
Well, your problem is not thrashing! You've got a minimal number of
faults, and no pagein/pageout. On the other hand, your CPU is busy.
I'd say that this is not a problem of working set or physical memory,
but merely that of garbage collecting. Increasing available memory
would only worsen the problem, when garbage collection will occur. On
the other hand, it would occur less often. Perhaps the solution would
be to decrease the garbage collecting threshold, collect more often
but collect less (hence, hang the user less, perhaps so little that
it's imperceptible).
You should check the garbage collection chapter of elisp info.
Oops, I realize that you said garbage collecting first. But that's
what you get for saying "thrash" when it's not:
thrash
5: move data into and out of core rather than performing useful
computation; "The system is thrashing again!"
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-07-27 12:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-27 5:29 garbage collecting! How to expand physical-mem used? David Combs
2004-07-27 12:28 ` Pascal Bourguignon
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.