Thrash reduction & RE: 2.4.0-test10 Sluggish After Load
-Original Message- From: Christoph Rohland [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 7:54 AM To: Rik van Riel Cc: Jonathan George; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: 2.4.0-test10 Sluggish After Load Hi Rik, >On Wed, 1 Nov 2000, Rik van Riel wrote: >> The 2.4 VM is basically pretty good when you're not >> thrashing and has efficient management of the VM until >> your working set reaches the size of physical memory. >> >> But once you hit the thrashing point, the VM falls >> flat on its face. This is a nasty surprise to many >> people and I am working on (trivial) thrashing control, >> but it's not there yet (and not all that important). > >I looked into this argument a little bit further: >In my usual stress tests 12 processes select a random memory object >out of 15 to mmap() or shmat() it and then access it serially. Each >segment is 66600 bytes and I have 8GB of memory. So at one time >there are at most 66600*12 bytes = 7.45GB memory attached and in >use. So I do not see that the machine qualifies as thrashing. Of >course the memory pressure is very high all the time since we have to >swap out unused segments. > >But the current VM does not behave good at all on that load. > >Greetings > Christoph I wonder how much of that memory is actually being used by your processes. My guess is that it's not the whole thing (unless you are running on a 64bit architecture). --Jonathan-- P.S. -- THRASH REDUCTION THOUGHTS - I have given some thought to the issue of thrash recovery, and I have come up with a simple (conceptually) way to implement a fair thrash reduction algorithm. However, since I know a minimal amount about the low level implementation of the Linux scheduler and VM beyond behavioral characteristics I would love to have some feedback since it should at least clear up some of my questions about kernel internals. My idea: If THIS process is paged in for consecutive scheduler slices Then Allow THIS process to run for XX% of the time it took to swap THIS process in. Where: THIS -- is the current runnable process. (multiple processes for SMP) XX% -- is the thrash recovery bias. (from 10-150% is probably reasonable) time it took to swap -- -- combined system swap time from fault. (until execution for this scheduler slice) What do you think? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Thrash reduction RE: 2.4.0-test10 Sluggish After Load
-Original Message- From: Christoph Rohland [mailto:[EMAIL PROTECTED]] Sent: Friday, November 03, 2000 7:54 AM To: Rik van Riel Cc: Jonathan George; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: 2.4.0-test10 Sluggish After Load Hi Rik, On Wed, 1 Nov 2000, Rik van Riel wrote: The 2.4 VM is basically pretty good when you're not thrashing and has efficient management of the VM until your working set reaches the size of physical memory. But once you hit the thrashing point, the VM falls flat on its face. This is a nasty surprise to many people and I am working on (trivial) thrashing control, but it's not there yet (and not all that important). I looked into this argument a little bit further: In my usual stress tests 12 processes select a random memory object out of 15 to mmap() or shmat() it and then access it serially. Each segment is 66600 bytes and I have 8GB of memory. So at one time there are at most 66600*12 bytes = 7.45GB memory attached and in use. So I do not see that the machine qualifies as thrashing. Of course the memory pressure is very high all the time since we have to swap out unused segments. But the current VM does not behave good at all on that load. Greetings Christoph I wonder how much of that memory is actually being used by your processes. My guess is that it's not the whole thing (unless you are running on a 64bit architecture). --Jonathan-- P.S. -- THRASH REDUCTION THOUGHTS - I have given some thought to the issue of thrash recovery, and I have come up with a simple (conceptually) way to implement a fair thrash reduction algorithm. However, since I know a minimal amount about the low level implementation of the Linux scheduler and VM beyond behavioral characteristics I would love to have some feedback since it should at least clear up some of my questions about kernel internals. My idea: If THIS process is paged in for consecutive scheduler slices Then Allow THIS process to run for XX% of the time it took to swap THIS process in. Where: THIS -- is the current runnable process. (multiple processes for SMP) XX% -- is the thrash recovery bias. (from 10-150% is probably reasonable) time it took to swap -- -- combined system swap time from fault. (until execution for this scheduler slice) What do you think? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test10 Sluggish After Load
-Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 01, 2000 11:06 AM To: Jonathan George Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: 2.4.0-test10 Sluggish After Load On Wed, 1 Nov 2000, Jonathan George wrote: > It might be helpful to show the current (post crippled) results > of top. Futhermore, a list of allocated ipc resources (share > memory, etc.) and open files (lsof) would be nice. The problem may well be that Oracle wants to clean up all memory at once, accessing much more memory than it did while under stress with more tricky access patterns. If this looks bad to you, compare the points where 2.2 starts thrashing and where 2.4 starts thrashing. You'll most likely (there must be a few corner cases where 2.2 does better ;)) see that 2.4 still runs fine where 2.2 performance has already "degraded heavily" and that 2.2 has "hit the wall" before 2.4 does so ... the difference just is that 2.4 hits the wall more suddenly ;) regards, Rik --- It sounded to me as if his machine never actually recovered from thrashing. Futhermore, even a thrashing case on a machine like that shouldn't last for more than about 10 minutes. It would be interesting to contrast FreeBSD's behavior if "simple" cleanup was the problem. BTW, I think that everyone is happy with the direction of the new VM. I'm looking forward to your upcoming enhancements which I hope will make it in to a later 2.4 release. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: KernelWiki for November: Dia de Muertos
Gary, Your post to the kernel mailing list is annoyingly patronizing, and _will_ get you flamed and added to kill files as a result. On the other hand working on kernel documentation is a worthy endeavor, so I would encourage you to try an approach which shows some respect to the people who make it all possible. To get the best, and most useful results I suggest browsing the docs directory in the latest source tree. Then attempt to come up with a structural model for describing the feature of the kernel to the best of your ability. Finally, post intelligent requests to flesh out the kernel documentation framework. An intelligent request might look like, "What is the best way to manage event requests in the Linux kernel (version 2.2, 2.4, 2.6)?", or "In what way are Linux threads different from POSIX threads (2.2, 2.4, 2.6)?", or "How do hook in a new filesystem to the Linux kernel (2.2, 2.4, 2.6)?", or "What SMP considerations need to be made in network device drivers?". By contrast your current approach is too annoying to accomplish much useful. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test10 Sluggish After Load
Matt, It might be helpful to show the current (post crippled) results of top. Futhermore, a list of allocated ipc resources (share memory, etc.) and open files (lsof) would be nice. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test10 Sluggish After Load
Matt, It might be helpful to show the current (post crippled) results of top. Futhermore, a list of allocated ipc resources (share memory, etc.) and open files (lsof) would be nice. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: KernelWiki for November: Dia de Muertos
Gary, Your post to the kernel mailing list is annoyingly patronizing, and _will_ get you flamed and added to kill files as a result. On the other hand working on kernel documentation is a worthy endeavor, so I would encourage you to try an approach which shows some respect to the people who make it all possible. To get the best, and most useful results I suggest browsing the docs directory in the latest source tree. Then attempt to come up with a structural model for describing the feature of the kernel to the best of your ability. Finally, post intelligent requests to flesh out the kernel documentation framework. An intelligent request might look like, "What is the best way to manage event requests in the Linux kernel (version 2.2, 2.4, 2.6)?", or "In what way are Linux threads different from POSIX threads (2.2, 2.4, 2.6)?", or "How do hook in a new filesystem to the Linux kernel (2.2, 2.4, 2.6)?", or "What SMP considerations need to be made in network device drivers?". By contrast your current approach is too annoying to accomplish much useful. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test10 Sluggish After Load
-Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 01, 2000 11:06 AM To: Jonathan George Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: 2.4.0-test10 Sluggish After Load On Wed, 1 Nov 2000, Jonathan George wrote: It might be helpful to show the current (post crippled) results of top. Futhermore, a list of allocated ipc resources (share memory, etc.) and open files (lsof) would be nice. The problem may well be that Oracle wants to clean up all memory at once, accessing much more memory than it did while under stress with more tricky access patterns. SNIP If this looks bad to you, compare the points where 2.2 starts thrashing and where 2.4 starts thrashing. You'll most likely (there must be a few corner cases where 2.2 does better ;)) see that 2.4 still runs fine where 2.2 performance has already "degraded heavily" and that 2.2 has "hit the wall" before 2.4 does so ... the difference just is that 2.4 hits the wall more suddenly ;) regards, Rik --- It sounded to me as if his machine never actually recovered from thrashing. Futhermore, even a thrashing case on a machine like that shouldn't last for more than about 10 minutes. It would be interesting to contrast FreeBSD's behavior if "simple" cleanup was the problem. BTW, I think that everyone is happy with the direction of the new VM. I'm looking forward to your upcoming enhancements which I hope will make it in to a later 2.4 release. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Patch to remove undefined C code
>-Original Message- >From: Alexander Viro [mailto:[EMAIL PROTECTED]] [snip] > >No arguments here, but proposed fixes were remarkably ugly. Example: > >tmp = *p++; >*q = f(tmp, *p++); >return p; > >is equivalent to more idiomatic > >*q = f(p[0], p[1]); >return p+2; > >And example with copying the string up to the comma... Yuck. Legal C != >decent C. Strongly agree. If the changes were an elegant solution to the ambiguities I never would have cared. In fact the whole reason I bothered to read the patch in the first place was that I feel strongly that something like that _was_ needed, but the solutions really seemed inferior to the original code in terms of elegance of expression. (Well some of the original code was pretty ugly too :-) --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Patch to remove undefined C code
-Original Message- From: Ben Pfaff [mailto:[EMAIL PROTECTED]] >Jonathan George <[EMAIL PROTECTED]> writes: > >> This patch has many bogus corrections where new variables were created, but >> the order of evaluation is already unambiguous. >> >> For example each comma separated clause in an expression is guaranteed to be >> completely evaluated before the next comma separated clause Including >> Assignments. > >No, that is not true in general. When the comma in question is >the comma operator, it is true. But when the comma separates >arguments to a function, it is not: the order of evaluation of >function arguments is implementation dependent. See C89 section >6.3.2.2 "Function calls": > > $ The order of evaluation of the function designator, the > $ arguments, and subexpressions within the arguments is > $ unspecified, ... >-- I sit surprised and corrected. With every version of every C compiler on every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using Manx C to E1 using Kai C++) the behavior has been the same for parameter lists as for the comma operator in this respect. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering? >"Premature optimization is the root of all evil." >--D. E. Knuth, "Structured Programming with go to Statements" Absolutely true. However, optimization of well tested, and algorithmically validated kernel code in a time critical section does not constitute premature optimization as I'm sure Donald would agree. I would be really interested to see how well the kernel compiler does at optimizing out all of these new tmp variables in terms of the resulting register utilization and performance. At least an assembler code size comparison is in order for each of these individual cases. That is my only real concern (other than all of that syntactically ambiguous code I have written over the last 15 years ;-) is that critical performance not be compromised in the kernel. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch to remove undefined C code
This patch has many bogus corrections where new variables were created, but the order of evaluation is already unambiguous. For example each comma separated clause in an expression is guaranteed to be completely evaluated before the next comma separated clause Including Assignments. It seems as if about half of the patched code simply makes it easier for the inexperienced C programmer to understand without actually fixing linguistic ambiguities, and at the same time introducing new variables which will clutter up the registers and the cache lines. Please don't apply this patch without consideration. --Jonathan--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch to remove undefined C code
This patch has many bogus corrections where new variables were created, but the order of evaluation is already unambiguous. For example each comma separated clause in an expression is guaranteed to be completely evaluated before the next comma separated clause Including Assignments. It seems as if about half of the patched code simply makes it easier for the inexperienced C programmer to understand without actually fixing linguistic ambiguities, and at the same time introducing new variables which will clutter up the registers and the cache lines. Please don't apply this patch without consideration. --Jonathan--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Patch to remove undefined C code
-Original Message- From: Ben Pfaff [mailto:[EMAIL PROTECTED]] Jonathan George [EMAIL PROTECTED] writes: This patch has many bogus corrections where new variables were created, but the order of evaluation is already unambiguous. For example each comma separated clause in an expression is guaranteed to be completely evaluated before the next comma separated clause Including Assignments. No, that is not true in general. When the comma in question is the comma operator, it is true. But when the comma separates arguments to a function, it is not: the order of evaluation of function arguments is implementation dependent. See C89 section 6.3.2.2 "Function calls": $ The order of evaluation of the function designator, the $ arguments, and subexpressions within the arguments is $ unspecified, ... -- I sit surprised and corrected. With every version of every C compiler on every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using Manx C to E1 using Kai C++) the behavior has been the same for parameter lists as for the comma operator in this respect. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering? "Premature optimization is the root of all evil." --D. E. Knuth, "Structured Programming with go to Statements" Absolutely true. However, optimization of well tested, and algorithmically validated kernel code in a time critical section does not constitute premature optimization as I'm sure Donald would agree. I would be really interested to see how well the kernel compiler does at optimizing out all of these new tmp variables in terms of the resulting register utilization and performance. At least an assembler code size comparison is in order for each of these individual cases. That is my only real concern (other than all of that syntactically ambiguous code I have written over the last 15 years ;-) is that critical performance not be compromised in the kernel. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Patch to remove undefined C code
-Original Message- From: Alexander Viro [mailto:[EMAIL PROTECTED]] [snip] No arguments here, but proposed fixes were remarkably ugly. Example: tmp = *p++; *q = f(tmp, *p++); return p; is equivalent to more idiomatic *q = f(p[0], p[1]); return p+2; And example with copying the string up to the comma... Yuck. Legal C != decent C. Strongly agree. If the changes were an elegant solution to the ambiguities I never would have cared. In fact the whole reason I bothered to read the patch in the first place was that I feel strongly that something like that _was_ needed, but the solutions really seemed inferior to the original code in terms of elegance of expression. (Well some of the original code was pretty ugly too :-) --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
>On Thu, 12 Oct 2000, Oliver Xymoron wrote: >> On Wed, 11 Oct 2000, Kiril Vidimce wrote: >> >> > My primary concern is whether a process can allocate more than 4 GB of >> > memory, rather than just be able to use more than 4 GB of physical >> > memory in the system. >> >> Define allocate. There are tricks you can play, but userspace is still a >> flat 32-bit address space per-process. > > >Allocate = malloc(). The process needs to be able to operate on >4 GB >chunks of memory. I understand that it's only a 32 bit address space >which is why I was surprised when I read that Linux 2.4.x will support >upwards of 64 GB's of memory. > > >Thanks for all the responses. > > >KV You can, of course, bank switch memory by using a shared segment and cloning additional process heaps. Obviously a _single_ 32bit address space can only access 4GB at a time. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, 12 Oct 2000, Oliver Xymoron wrote: On Wed, 11 Oct 2000, Kiril Vidimce wrote: My primary concern is whether a process can allocate more than 4 GB of memory, rather than just be able to use more than 4 GB of physical memory in the system. Define allocate. There are tricks you can play, but userspace is still a flat 32-bit address space per-process. Allocate = malloc(). The process needs to be able to operate on 4 GB chunks of memory. I understand that it's only a 32 bit address space which is why I was surprised when I read that Linux 2.4.x will support upwards of 64 GB's of memory. Thanks for all the responses. KV You can, of course, bank switch memory by using a shared segment and cloning additional process heaps. Obviously a _single_ 32bit address space can only access 4GB at a time. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
