Hi -
I have been looking into the tux2 webserver -
Man, what a thing of beauty. A web benchmark
that sends the load on the web server to 150
when running apache results in a load average
of maybe 2 when running tux, and much faster
results to boot - anyway, I digress....
I built 2.4.16+low-latency+preempt+tux2, and
started testing it. To my horror, the webserver
died - I checked the logs and found an oops -
(for your edification, I attach it below)
So, I figured, preempt and low latency don't
mix well - I'll just build a kernel with tux and
preempt.
To my horror, the new kernel without the
low latency patch oopsed immediately as
well, as soon as I started an apachebench
run from a remote testing box.
(for you edification, I include this oops also)
I removed the preempt patch and basically
compiled just 2.4.16+tux, and hammered on
it for several hours - rock solid.
So, there is an issue with tux and the preempt
patch - I've got big plans for tux atm, so for
now I will have to do without preempt -
Thanks & Regards,
jjs
On Tue, 27 Nov 2001, J Sloan wrote:
> I have been looking into the tux2 webserver -
> Man, what a thing of beauty. A web benchmark
> that sends the load on the web server to 150
> when running apache results in a load average
> of maybe 2 when running tux, and much faster
> results to boot - anyway, I digress....
Loadavg isn't much of a measure here, it's a measure of the length of the
runnable queue. If you've only got two processes because your server has a
thread per processor, then yes, you'll see lower loadavg, but not lower
load. A real measure would look at idle percentage and throughput.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Oliver Xymoron wrote:
> On Tue, 27 Nov 2001, J Sloan wrote:
>
> > I have been looking into the tux2 webserver -
> > Man, what a thing of beauty. A web benchmark
> > that sends the load on the web server to 150
> > when running apache results in a load average
> > of maybe 2 when running tux, and much faster
> > results to boot - anyway, I digress....
>
> Loadavg isn't much of a measure here, it's a measure of the length of the
> runnable queue. If you've only got two processes because your server has a
> thread per processor, then yes, you'll see lower loadavg, but not lower
> load. A real measure would look at idle percentage and throughput.
That's easily done, and we know that load average
is a measure of tasks waiting to run - but rather
than throw more statistics around, I can say that
a Linux desktop running tux remains responsive
under a http load that would tend to monopolize it's
attention under apache -
Now I'm not knocking apache of course, it's the
standard these days, and there's nothing more
flexible or reliable - but there is indeed a niche
for a small, blindingly fast server like tux - and I
intend to explore that niche in coming months.
cu
jjs
Oliver Xymoron wrote:
>
> On Tue, 27 Nov 2001, J Sloan wrote:
>
> > I have been looking into the tux2 webserver -
> > Man, what a thing of beauty. A web benchmark
> > that sends the load on the web server to 150
> > when running apache results in a load average
> > of maybe 2 when running tux, and much faster
> > results to boot - anyway, I digress....
>
> Loadavg isn't much of a measure here, it's a measure of the length of the
> runnable queue. If you've only got two processes because your server has a
> thread per processor, then yes, you'll see lower loadavg, but not lower
> load. A real measure would look at idle percentage and throughput.
Even idle percentage is quite misleading. Lots of interrupt
processing gets credited to the idle task and you don't see
it at all with normal accounting tools.
The `subtractive' approach is more accurate. See how much
processing capacity is left behind when all the foreground
task and interrupt processing is complete.
Grab http://www.zip.com.au/~akpm/linux/zc.tar.gz
Type make
run ./cyclesoak -C
run ./cyclesoak
easy.
On Tue, 2001-11-27 at 20:17, J Sloan wrote:
> So, there is an issue with tux and the preempt
> patch - I've got big plans for tux atm, so for
> now I will have to do without preempt -
Tux makes heavy use of per-CPU data and some of it is undoubtedly not
preempt-safe. It is probably trivial to fix but would take some
familiarity with the codebase...Ingo would know best. Its not on the
top of my todo list, but I will look into it.
Robert Love
Just to follow up, I compiled 2.4.16 with the
low latency patch from Andrew Morton, as
well as the 2.4.16-disk-i/o-responsiveness
patch from Andrew, and tux-full-2.4.16-A3.
I hammered tux all night with an apachebench
script, and it never hiccupped. So, while tux
and preempt don't play well together, tux and
low-latency seem to get along just fine.
Regards,
jjs
J Sloan wrote:
> I built 2.4.16+low-latency+preempt+tux2, and
> started testing it. To my horror, the webserver
> died - I checked the logs and found an oops -
> (for your edification, I attach it below)
>
> So, I figured, preempt and low latency don't
> mix well - I'll just build a kernel with tux and
> preempt.
>
> To my horror, the new kernel without the
> low latency patch oopsed immediately as
> well, as soon as I started an apachebench
> run from a remote testing box.
>
> (for you edification, I include this oops also)
>
> I removed the preempt patch and basically
> compiled just 2.4.16+tux, and hammered on
> it for several hours - rock solid.
>
> So, there is an issue with tux and the preempt
> patch - I've got big plans for tux atm, so for
> now I will have to do without preempt -
>
> Thanks & Regards,
>
> jjs
>
> -
> 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/
hi,
what is fast and slow interrupt ?
what is the difference between this ?
bye
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
On Wed, 2001-11-28 at 20:18, McEnroe wrote:
> what is fast and slow interrupt ?
> what is the difference between this ?
fast interrupts occur with interrupts disabled, and are expected to be
completed quickly -- they are performed by the interrupt handlers
themselves.
a slow interrupt occurs with interrupts enabled, such as bottom half
tasks.
Robert Love
On Thu, Nov 29, 2001 at 12:07:37PM -0500, Robert Love wrote:
> On Wed, 2001-11-28 at 20:18, McEnroe wrote:
>
> > what is fast and slow interrupt ?
> > what is the difference between this ?
>
> fast interrupts occur with interrupts disabled, and are expected to be
> completed quickly -- they are performed by the interrupt handlers
> themselves.
>
> a slow interrupt occurs with interrupts enabled, such as bottom half
> tasks.
>
IIRC, bottom half is mostly used by network packet processing.