Re: buffer cache patches - anybody willing to summarize?

Linus Torvalds (torvalds@transmeta.com)
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