> > isn't this a solution in search of a problem?
> > does it make sense to redesign parts of the kernel for the sole
> > purpose of making a completely unrealistic benchmark run faster?
>
> Irrespective of the usefulness of the "chat" benchmark, it seems
> that there is a problem of scalability
On Tue, Apr 17, 2001 at 04:19:16PM +0530, Maneesh Soni wrote:
> But still the throughput improvement is not there for my patch. the reason, I
> think, is that I didnot get too many hits to fget() routine. It will be helpful
> if you can tell how you got fget() chewing up more than its fair share
On Thu, Apr 12, 2001 at 08:51:18AM -0700, Anton Blanchard wrote:
>
> Hi,
>
> > Base (2.4.2) -
> > 100 Average Throughput = 39.628 MB/sec
> > 200 Average Throughput = 22.792 MB/sec
> >
> > Base + files_struct patch -
> > 100 Average Throughput = 39.874 MB/sec
> >
Hi Mike,
[I am not sure if my earlier mail from lycos went out or not, if
it did, I apologize]
On Mon, Apr 16, 2001 at 12:16:25PM -0400, Mark Hahn wrote:
> > The improvement in performance while runnig "chat" benchmark
> > (from http://lbs.sourceforge.net/) is about 30% in average throughput.
>
> The improvement in performance while runnig "chat" benchmark
> (from http://lbs.sourceforge.net/) is about 30% in average throughput.
isn't this a solution in search of a problem?
does it make sense to redesign parts of the kernel for the sole
purpose of making a completely unrealistic benchma
From: "Maneesh Soni" <[EMAIL PROTECTED]>
...
> Though I intend to do some
> profiling to look into this but it will be helpfull if you can tell me
if there
> is some known thing regarding this.
...
Another useful tool is Lockmeter, which gives you visibility to what's
happening with spinlock_t an
Hi,
> Base (2.4.2) -
> 100 Average Throughput = 39.628 MB/sec
> 200 Average Throughput = 22.792 MB/sec
>
> Base + files_struct patch -
> 100 Average Throughput = 39.874 MB/sec
> 200 Average Throughput = 23.174 MB/sec
>
> I found this value quite
On Wed, Apr 11, 2001 at 06:29:30PM -0700, Anton Blanchard wrote:
>
> > This patch provides a very good performance improvement in file
> > descriptor management for SMP linux kernel on a 4-way machine with the
> > expectation of even higher gains on higher end machines. The patch uses the
> >
> This patch provides a very good performance improvement in file
> descriptor management for SMP linux kernel on a 4-way machine with the
> expectation of even higher gains on higher end machines. The patch uses the
> read-copy-update mechanism for Linux, published earlier at the sourceforge
Scalable FD Management Using Read-Copy-Update
-
This patch provides a very good performance improvement in file
descriptor management for SMP linux kernel on a 4-way machine with the
expectation of even higher gains on higher end machines. The patch
10 matches
Mail list logo
