OT: Does Linux have any "Perfect Code"
Bryan Cantrill of Sun (ala DTrace) has a notion of perfect code: http://blogs.sun.com/bmc/entry/on_i_dreaming_in_code He also has some examples (from bottom comment section of above): Can you list a small number of examples of "software perfection"? Posted by Russell Leighton on November 14, 2007 at 04:02 AM PST # Russell, My canonical small example of perfection in Solaris would be Jeff Bonwick's mod-by-a-billion code in hrt2ts(): http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ common/os/timers.c#875 Solaris of course has lots of bigger, more complicated examples. Now on the one hand, one wants to refrain from pointing to thousands of lines of code and saying that there are no bugs therein, but on the other, there are many subsystems that have been in place and in heavy use for years without defect or modification. At the risk of being egocentric, the cyclic subsystem (which is executed at least 100 times per second on every Solaris system) had its last substantial fix over six years ago, and its last fix of any flavor over three years ago: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ common/os/cyclic.c Modesty (and the lack, of course, of a proof of its correctness) prevents me from calling the cyclic subsystem perfect -- but such as unknown defects remain, there are damn few of them, and we can say that they must be a result of highly usual (or at least, heretofore unseen) circumstances. A non-Solaris example -- and one that I've been known to use as the canonical example of the persistence of software -- is Super Mario Kart. This is a game that was developed (to its completion) fifteen years ago for the Super Nintendo console. Source code, to the best of my knowledge, is not publicly available and may indeed be lost -- but the binaries persist and (if my coworkers are any indication) remain in active use. Given the longevity of, say, Homer's Odyssey, there is reason to believe that Super Mario Kart will survive in perpetuity -- that thousands of years from now, twenty-somethings somewhere will be using the software exactly as it is used today. Is this perfection? Perhaps not -- but it also might not be discernible from perfection... Posted by Bryan Cantrill on November 14, 2007 at 07:51 AM PST # Does Linux have any such examples true software perfection? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Does Linux have any Perfect Code
Bryan Cantrill of Sun (ala DTrace) has a notion of perfect code: http://blogs.sun.com/bmc/entry/on_i_dreaming_in_code He also has some examples (from bottom comment section of above): Can you list a small number of examples of software perfection? Posted by Russell Leighton on November 14, 2007 at 04:02 AM PST # Russell, My canonical small example of perfection in Solaris would be Jeff Bonwick's mod-by-a-billion code in hrt2ts(): http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ common/os/timers.c#875 Solaris of course has lots of bigger, more complicated examples. Now on the one hand, one wants to refrain from pointing to thousands of lines of code and saying that there are no bugs therein, but on the other, there are many subsystems that have been in place and in heavy use for years without defect or modification. At the risk of being egocentric, the cyclic subsystem (which is executed at least 100 times per second on every Solaris system) had its last substantial fix over six years ago, and its last fix of any flavor over three years ago: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ common/os/cyclic.c Modesty (and the lack, of course, of a proof of its correctness) prevents me from calling the cyclic subsystem perfect -- but such as unknown defects remain, there are damn few of them, and we can say that they must be a result of highly usual (or at least, heretofore unseen) circumstances. A non-Solaris example -- and one that I've been known to use as the canonical example of the persistence of software -- is Super Mario Kart. This is a game that was developed (to its completion) fifteen years ago for the Super Nintendo console. Source code, to the best of my knowledge, is not publicly available and may indeed be lost -- but the binaries persist and (if my coworkers are any indication) remain in active use. Given the longevity of, say, Homer's Odyssey, there is reason to believe that Super Mario Kart will survive in perpetuity -- that thousands of years from now, twenty-somethings somewhere will be using the software exactly as it is used today. Is this perfection? Perhaps not -- but it also might not be discernible from perfection... Posted by Bryan Cantrill on November 14, 2007 at 07:51 AM PST # Does Linux have any such examples true software perfection? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What are the VM motivations??
I read this thread as asking the question:
If VM management is viewed as an optimization problem,
then what exactly is the function that you are optimizing and what are the
constraints?
If you could express that well with a even a very loose model, then
the code could be reviewed to see if it was really doing what was intended
and assumptions could be tested.
This seems like a reasonable request.
Jason McMullan wrote:
> On Sun, Jun 24, 2001 at 12:04:43PM -0300, Rik van Riel wrote:
> > OK. I challenge you to come up with:
> >
> > 1) the set of inputs for the neural network
> > 2) the set of outputs
> > 3) the goal for training the thing
> >
> > I'm pretty fed up with people who want to "change the VM"
> > but never give any details of their ideas.
>
> Uhh. That's not what I was ranting about. What I was
> ranting about is that we have never 'put to paper' the
> requirements ('motiviations') for a good VM, nor have we
> looked at said nonexistent list and figured out what instrumentation
> would be needed.
>
> I don't now that much about VM, but I do know a bunch of
> people each scratching their own itch, and most of them not looking
> at the bigger picture. Linus, RvR, etc. excepted. Mostly. ;^)
>
> The whole 'neural network' bit was mostly troll. Sorry,
> I got a little carried away at that point.
>
> --
> Jason McMullan, Senior Linux Consultant
> Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell
> [EMAIL PROTECTED], http://www.linuxcare.com/
> Linuxcare. Putting open source to work.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What are the VM motivations??
I read this thread as asking the question:
If VM management is viewed as an optimization problem,
then what exactly is the function that you are optimizing and what are the
constraints?
If you could express that well with a even a very loose model, then
the code could be reviewed to see if it was really doing what was intended
and assumptions could be tested.
This seems like a reasonable request.
Jason McMullan wrote:
On Sun, Jun 24, 2001 at 12:04:43PM -0300, Rik van Riel wrote:
OK. I challenge you to come up with:
1) the set of inputs for the neural network
2) the set of outputs
3) the goal for training the thing
I'm pretty fed up with people who want to change the VM
but never give any details of their ideas.
Uhh. That's not what I was ranting about. What I was
ranting about is that we have never 'put to paper' the
requirements ('motiviations') for a good VM, nor have we
looked at said nonexistent list and figured out what instrumentation
would be needed.
I don't now that much about VM, but I do know a bunch of
people each scratching their own itch, and most of them not looking
at the bigger picture. Linus, RvR, etc. excepted. Mostly. ;^)
The whole 'neural network' bit was mostly troll. Sorry,
I got a little carried away at that point.
--
Jason McMullan, Senior Linux Consultant
Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Putting open source to work.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
this is getting way OT...everyone wants make Linux work well for all programming methods as long as poor compromises are not made...most of the people that matter on this list can define "poor" so I am not worried about the future of Linux. Last 0.02 below and this should be take off the list. Davide Libenzi wrote: > > 1) HW is cheaper than software engineers time Most of the time this is true...kinda depends on the project and other constraints. I'd hate to make a system that has poor $$/hw when scaling it just because the programmers are lazy. > > > 2) to find Java developers is easier than to find C developers Good developers are hard to find , period. My experience is that there are a whole bunch of people out there that have ONLY coded Java and they should not be let near a computer. > > > 3) the ETA of the same project developed in Java is shorter than the same > project done in C > Very debatable ... and the point I was making was not about C ... for example, Java servlets and JSP are probably a very big part of the Java app "world"...I'd take PHP over that any day for apps that require a DHTML GUI on a database...just depends on what you are doing and your requirements...would you write a device driver in Java?... what I find stunning about Java (and I said this before) is that : "Java is not particularly good at anything (jack of all trades master of none)." > > This depend heavily on the type of project but these are points that every > software Co. has to face when starting a new project. > Yup...hard decisions. No silver bullet. > > - Davide -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Ben Greear wrote: > System-design and elegance are easy to get > in Java, and in fact are independent of language. Good c code will beat > Java in most cases, performance wise, but lately the difference has become > small enough not to matter for most applications. Rather a sweeping statement. I don't buy it...depends what you mean by "most applications". I bet 90% of the "most" would be better served by being written in Visual Basic (or Perl, or Python, or PHP pick your poison for a very high level language)...and if you really care about resource usage and/or performance you don't want a very high high level language and Java does not leap to mind as part of the set of credible alternatives. I had a company that gaves us a tech briefing of their system. They dumped mega-bucks into multiple Sun E1s they needed to run their Java apps... the were proud of their scalable design, just add more hardware! True, the high level design was fine and trivially scalable w/more hw BUT what a waste, if their app was done in C they could have had it run faster and it would have cost them significantly less (in the millions of $$). The lack of a good operating system _dependent_ interface makes running fast hard in Java when you need to do IO... yes, there is always JNI so you can add a little C to mmap a file or whatever, but if you are doing that, you slide down the slippery slope of justifying Java. That's just one aspect, don't get me started (e.g., memory mangement, method call overhead, type checking, yuk). > Speed is not the most > important feature in a great many programs, otherwise we'd all be using > assembly still. Agreed. It's a judgement call. I just think that Java is not particularly good at anything (jack of all trades master of none). -- ------- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Ben Greear wrote: snip System-design and elegance are easy to get in Java, and in fact are independent of language. Good c code will beat Java in most cases, performance wise, but lately the difference has become small enough not to matter for most applications. Rather a sweeping statement. I don't buy it...depends what you mean by most applications. I bet 90% of the most would be better served by being written in Visual Basic (or Perl, or Python, or PHP pick your poison for a very high level language)...and if you really care about resource usage and/or performance you don't want a very high high level language and Java does not leap to mind as part of the set of credible alternatives. I had a company that gaves us a tech briefing of their system. They dumped mega-bucks into multiple Sun E1s they needed to run their Java apps... the were proud of their scalable design, just add more hardware! True, the high level design was fine and trivially scalable w/more hw BUT what a waste, if their app was done in C they could have had it run faster and it would have cost them significantly less (in the millions of $$). The lack of a good operating system _dependent_ interface makes running fast hard in Java when you need to do IO... yes, there is always JNI so you can add a little C to mmap a file or whatever, but if you are doing that, you slide down the slippery slope of justifying Java. That's just one aspect, don't get me started (e.g., memory mangement, method call overhead, type checking, yuk). Speed is not the most important feature in a great many programs, otherwise we'd all be using assembly still. Agreed. It's a judgement call. I just think that Java is not particularly good at anything (jack of all trades master of none). -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
this is getting way OT...everyone wants make Linux work well for all programming methods as long as poor compromises are not made...most of the people that matter on this list can define poor so I am not worried about the future of Linux. Last 0.02 below and this should be take off the list. Davide Libenzi wrote: snip 1) HW is cheaper than software engineers time Most of the time this is true...kinda depends on the project and other constraints. I'd hate to make a system that has poor $$/hw when scaling it just because the programmers are lazy. 2) to find Java developers is easier than to find C developers Good developers are hard to find , period. My experience is that there are a whole bunch of people out there that have ONLY coded Java and they should not be let near a computer. 3) the ETA of the same project developed in Java is shorter than the same project done in C Very debatable ... and the point I was making was not about C ... for example, Java servlets and JSP are probably a very big part of the Java app world...I'd take PHP over that any day for apps that require a DHTML GUI on a database...just depends on what you are doing and your requirements...would you write a device driver in Java?... what I find stunning about Java (and I said this before) is that : Java is not particularly good at anything (jack of all trades master of none). This depend heavily on the type of project but these are points that every software Co. has to face when starting a new project. Yup...hard decisions. No silver bullet. - Davide -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Coroutines [was Re: threading question]
Any chance this or the equiv could become part of glibc?
This seems a very handy abstraction, in many apps
threads would then really only be needed for true parallelism.
Michael Rothwell wrote:
> Try this:
>
> http://lecker.essen.de/~froese/coro/
>
> -M
>
> On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
> >
> > Is there a user-space implemenation (library?) for coroutines that would work from
>C?
> >
> >
> > Alan Cox wrote:
> >
> > > > Can you provide any info and/or examples of co-routines? I'm curious to
> > > > see a good example of co-routines' "betterness."
> > >
> > > With co-routines you don't need
> > >
> > > 8K of kernel stack
> > > Scheduler overhead
> > > Fancy locking
> > >
> > > You don't get the automatic thread switching stuff though.
> > >
> > > So you might get code that reads like this (note that aio_ stuff works rather
> > > well combined with co-routines as it fixes a lack of asynchronicity in the
> > > unix disk I/O world)
> > >
> > > select()
> > >
> > > if(FD_ISSET(copier_fd))
> > > run_coroutine(_state);
> > >
> > > ...
> > >
> > > and the copier might be something like
> > >
> > > while(1)
> > > {
> > > // Yes 1 at a time is dumb but this is an example..
> > > // Yes Im ignoring EOF for this
> > > if(read(copier_fd, buf[bufptr], 1)==-1)
> > > {
> > > if(errno==-EWOULDBLOCK)
> > > {
> > > coroutine_return();
> > > continue;
> > > }
> > > }
> > > if(bufptr==255 || buf[bufptr]=='\n')
> > > {
> > > run_coroutine(run_command, buf);
> > > bufptr=0;
> > > }
> > > else
> > > bufptr++;
> > > }
> > >
> > > it lets you express a state machine as a set of multiple such small state
> > > machines instead. run_coroutine() will continue a routine where it last
> > > coroutine_return()'d from. Thus in the above case we are expressing read
> > > bytes until you see a new line cleanly - not mangled in with keeping state
> > > in global structures but by using natural C local variables and code flow
> > >
> > > Alan
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> > --
> > ---
> > Russell Leighton[EMAIL PROTECTED]
> > ---
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> Michael Rothwell
> [EMAIL PROTECTED]
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Coroutines [was Re: threading question]
Any chance this or the equiv could become part of glibc?
This seems a very handy abstraction, in many apps
threads would then really only be needed for true parallelism.
Michael Rothwell wrote:
Try this:
http://lecker.essen.de/~froese/coro/
-M
On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
Is there a user-space implemenation (library?) for coroutines that would work from
C?
Alan Cox wrote:
Can you provide any info and/or examples of co-routines? I'm curious to
see a good example of co-routines' betterness.
With co-routines you don't need
8K of kernel stack
Scheduler overhead
Fancy locking
You don't get the automatic thread switching stuff though.
So you might get code that reads like this (note that aio_ stuff works rather
well combined with co-routines as it fixes a lack of asynchronicity in the
unix disk I/O world)
select()
if(FD_ISSET(copier_fd))
run_coroutine(copier_state);
...
and the copier might be something like
while(1)
{
// Yes 1 at a time is dumb but this is an example..
// Yes Im ignoring EOF for this
if(read(copier_fd, buf[bufptr], 1)==-1)
{
if(errno==-EWOULDBLOCK)
{
coroutine_return();
continue;
}
}
if(bufptr==255 || buf[bufptr]=='\n')
{
run_coroutine(run_command, buf);
bufptr=0;
}
else
bufptr++;
}
it lets you express a state machine as a set of multiple such small state
machines instead. run_coroutine() will continue a routine where it last
coroutine_return()'d from. Thus in the above case we are expressing read
bytes until you see a new line cleanly - not mangled in with keeping state
in global structures but by using natural C local variables and code flow
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Michael Rothwell
[EMAIL PROTECTED]
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
Nuther anecdote: I was creating a big swapfile on ext2 (because 2.4.5 needs too much swap) with dd (SCSI disk on Sym53c8-something controller) and corrupted the partition THEN fsck would cause the kernel to panic. I thought I had some bad hw ... the box sits on my office floor waiting resurrection. Eugene Crosser wrote: > In article <[EMAIL PROTECTED]>, > Alan Cox <[EMAIL PROTECTED]> writes: > >> Folks, I believe I have a reproducible test case which corrupts data in > >> 2.4.5. > > > > 2.4.5 has an out of date 3ware driver that is short > > These days I observed massive FS curruption on vanilla 2.4.5, > SCSI disk on Sym53c8-something controller (UW). I did not notice > any problems since 2.4.5 was published, they seem to have surfaced > immediately after I created a rather big file capturing video with > broadcast2000 (video card is bt848). Filesystem is ext2. > > Eugene > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
Nuther anecdote: I was creating a big swapfile on ext2 (because 2.4.5 needs too much swap) with dd (SCSI disk on Sym53c8-something controller) and corrupted the partition THEN fsck would cause the kernel to panic. I thought I had some bad hw ... the box sits on my office floor waiting resurrection. Eugene Crosser wrote: In article [EMAIL PROTECTED], Alan Cox [EMAIL PROTECTED] writes: Folks, I believe I have a reproducible test case which corrupts data in 2.4.5. 2.4.5 has an out of date 3ware driver that is short These days I observed massive FS curruption on vanilla 2.4.5, SCSI disk on Sym53c8-something controller (UW). I did not notice any problems since 2.4.5 was published, they seem to have surfaced immediately after I created a rather big file capturing video with broadcast2000 (video card is bt848). Filesystem is ext2. Eugene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
bert hubert wrote: > > > I see lots of people only using: > pthread_create()/pthread_join() > mutex_lock/unlock > sem_post/sem_wait > no signals > > My gut feeling is that you could implement this subset in a way that is both > fast and right - although it would not be 'pthreads compliant'. Can anybody > confirm this feeling? ... add condition variables (maybe a small per-thread storage area) and I'd toss out pthreads for most apps I write...especially if it is very efficient. -- ------- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
bert hubert wrote: stuff deleted I see lots of people only using: pthread_create()/pthread_join() mutex_lock/unlock sem_post/sem_wait no signals My gut feeling is that you could implement this subset in a way that is both fast and right - although it would not be 'pthreads compliant'. Can anybody confirm this feeling? ... add condition variables (maybe a small per-thread storage area) and I'd toss out pthreads for most apps I write...especially if it is very efficient. -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
Any recommendations for alternate threading packages? Alexander Viro wrote: > On Tue, 12 Jun 2001, Kip Macy wrote: > > > implementation of threads is not an accidental oversight, threads are not > > looked upon favorably by most of the core linux kernel hackers. A quote > > s/threads/POSIX threads/. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- ------- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
Any recommendations for alternate threading packages? Alexander Viro wrote: On Tue, 12 Jun 2001, Kip Macy wrote: implementation of threads is not an accidental oversight, threads are not looked upon favorably by most of the core linux kernel hackers. A quote s/threads/POSIX threads/. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
I also need some 2.4 features and can't really goto 2.2. I would have to agree that the VM is too broken for production...looking forward to the work that (hopefully) will be in 2.4.6 to resolve these issues. "Jeffrey W. Baker" wrote: > On Tue, 5 Jun 2001, Derek Glidden wrote: > > > > > After reading the messages to this list for the last couple of weeks and > > playing around on my machine, I'm convinced that the VM system in 2.4 is > > still severely broken. > > > > This isn't trying to test extreme low-memory pressure, just how the > > system handles recovering from going somewhat into swap, which is a real > > day-to-day problem for me, because I often run a couple of apps that > > most of the time live in RAM, but during heavy computation runs, can go > > a couple hundred megs into swap for a few minutes at a time. Whenever > > that happens, my machine always starts acting up afterwards, so I > > started investigating and found some really strange stuff going on. > > I reboot each of my machines every week, to take them offline for > intrusion detection. I use 2.4 because I need advanced features of > iptables that ipchains lacks. Because the 2.4 VM is so broken, and > because my machines are frequently deeply swapped, they can sometimes take > over 30 minutes to shutdown. They hang of course when the shutdown rc > script turns off the swap. The first few times this happened I assumed > they were dead. > > So, unlike what certain people like to repeatedly claim, the 2.4 VM > problems are causing havoc in the real world. > > -jwb > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
I also need some 2.4 features and can't really goto 2.2. I would have to agree that the VM is too broken for production...looking forward to the work that (hopefully) will be in 2.4.6 to resolve these issues. Jeffrey W. Baker wrote: On Tue, 5 Jun 2001, Derek Glidden wrote: After reading the messages to this list for the last couple of weeks and playing around on my machine, I'm convinced that the VM system in 2.4 is still severely broken. This isn't trying to test extreme low-memory pressure, just how the system handles recovering from going somewhat into swap, which is a real day-to-day problem for me, because I often run a couple of apps that most of the time live in RAM, but during heavy computation runs, can go a couple hundred megs into swap for a few minutes at a time. Whenever that happens, my machine always starts acting up afterwards, so I started investigating and found some really strange stuff going on. I reboot each of my machines every week, to take them offline for intrusion detection. I use 2.4 because I need advanced features of iptables that ipchains lacks. Because the 2.4 VM is so broken, and because my machines are frequently deeply swapped, they can sometimes take over 30 minutes to shutdown. They hang of course when the shutdown rc script turns off the swap. The first few times this happened I assumed they were dead. So, unlike what certain people like to repeatedly claim, the 2.4 VM problems are causing havoc in the real world. -jwb - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
I have a 2.4.5-ac3 box with 1G RAM and 2.6G Swapfirst time developers hit apache/php/zendcache after reboot and it swapped to a stop. I stop/restarted apache and it seems very happy...can't goto production like this tho :( Alan Cox wrote: > > My system has 128 Meg of Swap and RAM. > > Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap > with 2.4. > > Marcelo is working to change that but right now you are running something > explicitly explained as not going to work as you want > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- ------- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
I have a 2.4.5-ac3 box with 1G RAM and 2.6G Swapfirst time developers hit apache/php/zendcache after reboot and it swapped to a stop. I stop/restarted apache and it seems very happy...can't goto production like this tho :( Alan Cox wrote: My system has 128 Meg of Swap and RAM. Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap with 2.4. Marcelo is working to change that but right now you are running something explicitly explained as not going to work as you want - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
"copy this fd to that one, and optimize that if you can" ... isn't this Larry M's "splice" (http://www.bitmover.com/lm/papers/splice.ps)? Andreas Dilger wrote: > Roger Wolff writes: > > I'd prefer an interface that says "copy this fd to that one, and > > optimize that if you can". > > > > For example, copying a file from one disk to another. I'm pretty sure > > that some efficiency can be gained if you don't need to handle the > > possibility of the userspace program accessing the data in between the > > read and the write. Sure this may not qualify as a "trivial > > optimization, that can be done with the existing infrastructure" right > > now, but programs that want to indicate "kernel, please optimize this > > if you can" can say so. > > Actually, this is a great example, because at one point I was working > on a device interface which would offload all of the disk-disk copying > overhead to the disks themselves, and not involve the CPU/RAM at all. > > I seem to recall that I2O promised something along these lines as well > (i.e. direct device-device communication). > > Cheers, Andreas > -- > Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert > - > 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/ -- - Russell Leighton [EMAIL PROTECTED] http://www.247media.com Company Vision: To be the preeminent global provider of interactive marketing solutions and services. - - 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: Is sendfile all that sexy?
"copy this fd to that one, and optimize that if you can" ... isn't this Larry M's "splice" (http://www.bitmover.com/lm/papers/splice.ps)? Andreas Dilger wrote: Roger Wolff writes: I'd prefer an interface that says "copy this fd to that one, and optimize that if you can". For example, copying a file from one disk to another. I'm pretty sure that some efficiency can be gained if you don't need to handle the possibility of the userspace program accessing the data in between the read and the write. Sure this may not qualify as a "trivial optimization, that can be done with the existing infrastructure" right now, but programs that want to indicate "kernel, please optimize this if you can" can say so. Actually, this is a great example, because at one point I was working on a device interface which would offload all of the disk-disk copying overhead to the disks themselves, and not involve the CPU/RAM at all. I seem to recall that I2O promised something along these lines as well (i.e. direct device-device communication). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/ -- - Russell Leighton [EMAIL PROTECTED] http://www.247media.com Company Vision: To be the preeminent global provider of interactive marketing solutions and services. - - 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/
