Messages in this thread |  | | | From | (Linus Torvalds) | | Subject | Re: buffer cache patches - anybody willing to summarize? | | Date | 6 Aug 1997 17:31:31 GMT |
| |
In article <199708060107.UAA22469@mango.mymenus.com>, Pete Harlan <harlan@mymenus.com> wrote: >Jeff Wiegley <wiegley@usc.edu> writes: > >> But, since the main purpose of 2.1.X -> 2.2/3.0 is the inclusion of >> proper and complete SMP support, I don't think that any SMP patches >> should be considered for the 2.0 tree. Only if they fix a gross security > >All SMP _bugfixes_ should go into 2.0. 2.2 improves SMP performance, >not reliability.
No. 2.2 improves SMP. It's not a matter of performance vs reliability, it's simply a very general qualitative matter.
It' sentirely possible that we cannot fix all the bugs in 2.0.x wrt SMP, simply because fixing them may involve a rewrite of some _very_ fundamental assumptions. And guess what has been done in 2.1.x...
>> SMP in 2.0 is ALPHA code, use at your own risk. If you really > >It was alpha a year ago. SMP was one of the flagship claims of 2.0. >SMP and multi-platform support were chief reasons for numbering it 2.0 >instead of 1.4.
The _ability_ to work on different architectures and being able to use multiple CPU's was the reason for the 2.0 numbering jump.
That doesn't mean that a ".0" release is necessarily ever going to be completly stable. 2.2 will have a much better SMP setup, along with a much wider base of supported architectures.
The fact that SMP has problems in 2.0 doesn't make the 2.0 numbering invalid. Linux-1.0 was the first version with reasonably stable networking, but that never meant that the networking code was very good: 1.2 was a major step in being correct on the network.
In short: I'd be very happy to be able to say that SMP is rock solid on 2.0.x, but I know why I ended up redoing the SMP code in 2.1, and while one concern was performance, let's just say that it was the secondary one for a long time.
Linus
|  |