> On Fri, Nov 16, 2001 at 01:48:59PM -0800, Gerrit Huizenga wrote:
> > This particular problem showed up from a Netbench run on a 4-way.
> > About 24% of the kernel time was from spinning on kernel_flag, with
> > 10% of the total time specifically originating in posix_lock_file.
> That's great. Now, what application or class of applications does
> Netbench represent? I seriously want to fix file locking, but I
> want something to point at to justify changes. And a benchmark doesn't
> represent that unless it's a good simulator of a real world situation.
This was the basis for a set of filesystem throughput and performance
tests. It turns out that journaling filesystems hit this harder.
There are entire classes of custom high end applications that rely
on user level files and filesystem throughput for their overall
performance. I believe, for instance, BAAN was one major corporate
app that did this, there are tons of others at the high end.
Unfortunately, I don't know if we can disclose to you all of the
individual proprietary or custom workloads that we hear about; the
best we can do is try to roll up behaviors and analyse subsystems
to improve those that are hottest.
And no benchmark in the world is a good simulator of a real world
situation. So are you presenting me with a no-win game here? Or
would you like to tell me what applications the Fortune 1000 are
using that involve Linux on N-way systems? We deal with customer
situations where they won't even tell us, but they'll point us at
some NDA numbers that point out a bad filesystem. We are trying
to aggregate that into a smaller set of benchmarks when possible.
> > I know you aren't looking for corporate support or anything ;-) but
> > we __are__ trying to get Linux ready to sell on 4-cpu, 8-cpu, 16-cpu,
> > 128-cpu, etc. machines sometime before the end of the next millenia.
> I know, and I think you're going about it in the wrong way. I do support
> removing use of lock_kernel from locks.c and I'm still annoyed akpm
> added it back.
Okay, spell out for me what the right way is. I (and IBM and the LSE
gorup in general) are more than willing to take community input (heck
we've already taken an enormous amount of input, flak, support, reviews,
flames, etc. ;-) but share your thoughts about how we should go about
it the right way. I would love to know. Usually I ask that question
and I get silence or some good comments suggesting that we *are* doing
it the right way.
> > We are looking for generally small patches for 2.4 when possible (with
> > the expectation that 2.5 will HAVE to be better ;-), hence Rick's
> > request.
> > Do you have any insight on how to approach this particular problem
> > with an eye towards a solution that might easily be backported to 2.4
> > (and in the meantime, tested on 2.4)?
> I have done an analysis of where we can use a spinlock instead of the BKL;
> that's not on a system I can get access to for the next week, but I'll
> dig it up when I have a chance. It's a patch I would have submitted
> if I didn't feel so strongly about stabilising 2.4, and I didn't have
> largescale changes planned for 2.5.
If you make it available, we can include it with internal testing, which
includes Cerberus testing, STP testing, it can be included in the LSE
roll-up patch, it can be tested with Netbench on 2-4-8-way systems, etc.
We are trying to bring a few resources to bear to help out in both making
Linux more stable and making it scale better.
> Revolutions do not require corporate support.
The revolution is nearly over. We are about to become victims
of our own success.