Hi!
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but
Hi!
IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
Hi!
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but
On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
> David Weinehall wrote:
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays
On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
David Weinehall wrote:
IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have
Hi!
IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
On Thu, 24 May 2001, Rik van Riel wrote:
> > > > OK.. let's forget about throughput for a moment and consider
> > > > those annoying reports of 0 order allocations failing :)
> > >
> > > Those are ok. All failing 0 order allocations are either
> > > atomic allocations or GFP_BUFFER allocations.
On Thu, 24 May 2001, Mike Galbraith wrote:
> On Thu, 24 May 2001, Rik van Riel wrote:
> > On Thu, 24 May 2001, Mike Galbraith wrote:
> > > On Sun, 20 May 2001, Rik van Riel wrote:
> > >
> > > > Remember that inactive_clean pages are always immediately
> > > > reclaimable by __alloc_pages(), if
On Thu, 24 May 2001, Rik van Riel wrote:
> On Thu, 24 May 2001, Mike Galbraith wrote:
> > On Sun, 20 May 2001, Rik van Riel wrote:
> >
> > > Remember that inactive_clean pages are always immediately
> > > reclaimable by __alloc_pages(), if you measured a performance
> > > difference by freeing
On Thu, 24 May 2001, Mike Galbraith wrote:
> On Sun, 20 May 2001, Rik van Riel wrote:
>
> > Remember that inactive_clean pages are always immediately
> > reclaimable by __alloc_pages(), if you measured a performance
> > difference by freeing pages in a different way I'm pretty sure
> > it's a
On Sun, 20 May 2001, Rik van Riel wrote:
> Remember that inactive_clean pages are always immediately
> reclaimable by __alloc_pages(), if you measured a performance
> difference by freeing pages in a different way I'm pretty sure
> it's a side effect of something else. What that something
>
On Sun, 20 May 2001, Rik van Riel wrote:
Remember that inactive_clean pages are always immediately
reclaimable by __alloc_pages(), if you measured a performance
difference by freeing pages in a different way I'm pretty sure
it's a side effect of something else. What that something
else is
On Thu, 24 May 2001, Mike Galbraith wrote:
On Sun, 20 May 2001, Rik van Riel wrote:
Remember that inactive_clean pages are always immediately
reclaimable by __alloc_pages(), if you measured a performance
difference by freeing pages in a different way I'm pretty sure
it's a side effect
On Thu, 24 May 2001, Rik van Riel wrote:
On Thu, 24 May 2001, Mike Galbraith wrote:
On Sun, 20 May 2001, Rik van Riel wrote:
Remember that inactive_clean pages are always immediately
reclaimable by __alloc_pages(), if you measured a performance
difference by freeing pages in a
On Thu, 24 May 2001, Mike Galbraith wrote:
On Thu, 24 May 2001, Rik van Riel wrote:
On Thu, 24 May 2001, Mike Galbraith wrote:
On Sun, 20 May 2001, Rik van Riel wrote:
Remember that inactive_clean pages are always immediately
reclaimable by __alloc_pages(), if you measured a
On Thu, 24 May 2001, Rik van Riel wrote:
OK.. let's forget about throughput for a moment and consider
those annoying reports of 0 order allocations failing :)
Those are ok. All failing 0 order allocations are either
atomic allocations or GFP_BUFFER allocations. I guess we
David Weinehall wrote:
> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and 32MB of swap as a
>Time to hunt around for a 386 or 486 which is limited to such
>a small amount of RAM ;)
I've got an old knackered 486DX/33 with 8Mb RAM (in 30-pin SIMMs, woohoo!),
a flat CMOS battery, a 2Gb Maxtor HD that needs a low-level format every
year, and no case. It isn't running anything right now...
On Mon, 21 May 2001, David Weinehall wrote:
> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and
On Mon, 21 May 2001, David Weinehall wrote:
IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB
Time to hunt around for a 386 or 486 which is limited to such
a small amount of RAM ;)
I've got an old knackered 486DX/33 with 8Mb RAM (in 30-pin SIMMs, woohoo!),
a flat CMOS battery, a 2Gb Maxtor HD that needs a low-level format every
year, and no case. It isn't running anything right now...
David Weinehall wrote:
IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a
On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
> Hi!
>
> > > You're right. It should never dump too much data at once. OTOH, if
> > > those cleaned pages are really old (front of reclaim list), there's no
> > > value in keeping them either. Maybe there should be a slow bleed
Hi!
> > You're right. It should never dump too much data at once. OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either. Maybe there should be a slow bleed for
> > mostly idle or lightly loaded conditions.
>
> If you don't think
Hi,
On Sun, May 20, 2001 at 07:04:31AM -0300, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> >
> > Looking at the locking and trying to think SMP (grunt) though, I
> > don't like the thought of taking two locks for each page until
>
> > 100%. The data in that block is
Hi,
On Sun, May 20, 2001 at 07:04:31AM -0300, Rik van Riel wrote:
On Sun, 20 May 2001, Mike Galbraith wrote:
Looking at the locking and trying to think SMP (grunt) though, I
don't like the thought of taking two locks for each page until
100%. The data in that block is toast anyway.
Hi!
You're right. It should never dump too much data at once. OTOH, if
those cleaned pages are really old (front of reclaim list), there's no
value in keeping them either. Maybe there should be a slow bleed for
mostly idle or lightly loaded conditions.
If you don't think it's
On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
Hi!
You're right. It should never dump too much data at once. OTOH, if
those cleaned pages are really old (front of reclaim list), there's no
value in keeping them either. Maybe there should be a slow bleed for
mostly
On Sun, 20 May 2001, Marcelo Tosatti wrote:
> On Sat, 19 May 2001, Mike Galbraith wrote:
>
> > @@ -1054,7 +1033,7 @@
> > if (!zone->size)
> > continue;
> >
> > - while (zone->free_pages < zone->pages_low) {
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> > On 20 May 2001, Zlatko Calusic wrote:
>
> > > Also in all recent kernels, if the machine is swapping, swap cache
> > > grows without limits and is hard to recycle, but then again that is
> > > a known
On Sat, 19 May 2001, Mike Galbraith wrote:
> @@ -1054,7 +1033,7 @@
> if (!zone->size)
> continue;
>
> - while (zone->free_pages < zone->pages_low) {
> + while
On Sun, 20 May 2001, Mike Galbraith wrote:
> On 20 May 2001, Zlatko Calusic wrote:
> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
>
> This one bugs me. I do not see that and
On Sun, 20 May 2001, Mike Galbraith wrote:
> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
>
> This one bugs me. I do not see that and can't understand why.
To throw away
On 20 May 2001, Zlatko Calusic wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters. The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which
On Sun, 20 May 2001, Ingo Oeser wrote:
> On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> > I'm not sure why that helps. I didn't put it in as a trick or
> > anything though. I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free
Mike Galbraith <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
>
> > That's the main problem with static parameters. The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the
On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> I'm not sure why that helps. I didn't put it in as a trick or
> anything though. I put it in because it didn't seem like a
> good idea to ever have more cleaned pages than free pages at a
> time when we're yammering for help.. so
On Sun, 20 May 2001, Mike Galbraith wrote:
> but ;-)
>
> Looking at the locking and trying to think SMP (grunt) though, I
> don't like the thought of taking two locks for each page until
> 100%. The data in that block is toast anyway. A big hairy SMP
> box has to feel reclaim_page(). (they
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
>
> > You're right. It should never dump too much data at once. OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either. Maybe there should be a
On Sun, 20 May 2001, Mike Galbraith wrote:
> You're right. It should never dump too much data at once. OTOH, if
> those cleaned pages are really old (front of reclaim list), there's no
> value in keeping them either. Maybe there should be a slow bleed for
> mostly idle or lightly loaded
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> >
> > I'm not sure why that helps. I didn't put it in as a trick or
> > anything though. I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free pages at a
> > time
On Sun, 20 May 2001, Mike Galbraith wrote:
> On Sat, 19 May 2001, Rik van Riel wrote:
> > On Sat, 19 May 2001, Mike Galbraith wrote:
> > > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> > >
> > > > That's the main problem with static parameters. The problem you are
> > > > trying to solve is
On Sun, 20 May 2001, Mike Galbraith wrote:
On Sat, 19 May 2001, Rik van Riel wrote:
On Sat, 19 May 2001, Mike Galbraith wrote:
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally
On Sun, 20 May 2001, Rik van Riel wrote:
On Sun, 20 May 2001, Mike Galbraith wrote:
I'm not sure why that helps. I didn't put it in as a trick or
anything though. I put it in because it didn't seem like a
good idea to ever have more cleaned pages than free pages at a
time when we're
On Sun, 20 May 2001, Mike Galbraith wrote:
You're right. It should never dump too much data at once. OTOH, if
those cleaned pages are really old (front of reclaim list), there's no
value in keeping them either. Maybe there should be a slow bleed for
mostly idle or lightly loaded
On Sun, 20 May 2001, Rik van Riel wrote:
On Sun, 20 May 2001, Mike Galbraith wrote:
You're right. It should never dump too much data at once. OTOH, if
those cleaned pages are really old (front of reclaim list), there's no
value in keeping them either. Maybe there should be a slow
On Sun, 20 May 2001, Mike Galbraith wrote:
but ;-)
Looking at the locking and trying to think SMP (grunt) though, I
don't like the thought of taking two locks for each page until
100%. The data in that block is toast anyway. A big hairy SMP
box has to feel reclaim_page(). (they
On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
I'm not sure why that helps. I didn't put it in as a trick or
anything though. I put it in because it didn't seem like a
good idea to ever have more cleaned pages than free pages at a
time when we're yammering for help.. so I
Mike Galbraith [EMAIL PROTECTED] writes:
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic numbers tend to suck in the VM.)
Magic
On Sun, 20 May 2001, Ingo Oeser wrote:
On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
I'm not sure why that helps. I didn't put it in as a trick or
anything though. I put it in because it didn't seem like a
good idea to ever have more cleaned pages than free pages at a
On 20 May 2001, Zlatko Calusic wrote:
Mike Galbraith [EMAIL PROTECTED] writes:
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why
On Sun, 20 May 2001, Mike Galbraith wrote:
Also in all recent kernels, if the machine is swapping, swap cache
grows without limits and is hard to recycle, but then again that is
a known problem.
This one bugs me. I do not see that and can't understand why.
To throw away dirty and
On Sun, 20 May 2001, Mike Galbraith wrote:
On 20 May 2001, Zlatko Calusic wrote:
Also in all recent kernels, if the machine is swapping, swap cache
grows without limits and is hard to recycle, but then again that is
a known problem.
This one bugs me. I do not see that and can't
On Sat, 19 May 2001, Mike Galbraith wrote:
@@ -1054,7 +1033,7 @@
if (!zone-size)
continue;
- while (zone-free_pages zone-pages_low) {
+ while (zone-free_pages
On Sun, 20 May 2001, Rik van Riel wrote:
On Sun, 20 May 2001, Mike Galbraith wrote:
On 20 May 2001, Zlatko Calusic wrote:
Also in all recent kernels, if the machine is swapping, swap cache
grows without limits and is hard to recycle, but then again that is
a known problem.
This
On Sun, 20 May 2001, Marcelo Tosatti wrote:
On Sat, 19 May 2001, Mike Galbraith wrote:
@@ -1054,7 +1033,7 @@
if (!zone-size)
continue;
- while (zone-free_pages zone-pages_low) {
+
On Sun, 20 May 2001, Dieter Nützel wrote:
> > > Three back to back make -j 30 runs for three different kernels.
> > > Swap cache numbers are taken immediately after last completion.
> >
> > The performance increase is nice, though. Do you see similar
> > changes in different kinds of workloads
On Sat, 19 May 2001, Rik van Riel wrote:
> On Sat, 19 May 2001, Mike Galbraith wrote:
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters. The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which is also
> >
> > Three back to back make -j 30 runs for three different kernels.
> > Swap cache numbers are taken immediately after last completion.
>
> The performance increase is nice, though. Do you see similar
> changes in different kinds of workloads ?
I you have a patch against 2.4.4-ac11 I will do
On Sat, 19 May 2001, Mike Galbraith wrote:
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
>
> > That's the main problem with static parameters. The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
>
>
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> That's the main problem with static parameters. The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)
Magic numbers might be sucking some performance right
On Fri, 18 May 2001, Rik van Riel wrote:
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> > On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
> >
> > > This is the core of why we cannot (IMHO) have a discussion
> > > of whether a patch introducing new VM tunables can go in:
> > >
On Fri, 18 May 2001, Rik van Riel wrote:
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
This is the core of why we cannot (IMHO) have a discussion
of whether a patch introducing new VM tunables can go in:
there is no
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic numbers tend to suck in the VM.)
Magic numbers might be sucking some performance right now
On Sat, 19 May 2001, Mike Galbraith wrote:
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic numbers tend to suck in the VM.)
Magic numbers
Three back to back make -j 30 runs for three different kernels.
Swap cache numbers are taken immediately after last completion.
The performance increase is nice, though. Do you see similar
changes in different kinds of workloads ?
I you have a patch against 2.4.4-ac11 I will do some
On Sat, 19 May 2001, Rik van Riel wrote:
On Sat, 19 May 2001, Mike Galbraith wrote:
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
That's the main problem with static parameters. The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic
On Sun, 20 May 2001, Dieter Nützel wrote:
Three back to back make -j 30 runs for three different kernels.
Swap cache numbers are taken immediately after last completion.
The performance increase is nice, though. Do you see similar
changes in different kinds of workloads ?
I you
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
>
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what
On Fri, May 18, 2001 at 11:12:32PM -0300, Rik van Riel wrote:
> Basic rule for VM: once you start swapping, you cannot
> win; All you can do is make sure no situation loses
> really badly and most situations perform reasonably.
Do you mean paging in general or thrashing?
I always thought:
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
>
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what would need
Hi,
On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
> This is the core of why we cannot (IMHO) have a discussion
> of whether a patch introducing new VM tunables can go in:
> there is no clear overview of exactly what would need to be
> tunable and how it would help.
It's worse
On Fri, 18 May 2001, Mike Galbraith wrote:
> While I'd love to have more control, I can't say I have a clear
> picture of exactly how I'd like those knobs to look. I always
> start out trying to get it to seek the right behavior.. :) and
> end up fighting so many different fires I get lost in
> Anyway, the bug is in 2.4.4, not in 2.4.4-ac10: I am really sorry for
> having loosing your time. With 2.4.4-ac9 with my fdomain, everything is
> also working great ;-)
Great.
[Crosses another bug off]
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, 18 May 2001, Ingo Oeser wrote:
> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> > On Fri, 18 May 2001, Ingo Oeser wrote:
> >
> > > Rik: Would you take patches for such a tradeoff sysctl?
> >
> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point
On Fri, 18 May 2001, Ingo Oeser wrote:
> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point out that
> > up to now nobody has described exactly WHAT tradeoff
> > they'd like to make tunable and why...
>
>
On Fri, 18 May 2001, Rik van Riel wrote:
> On Fri, 18 May 2001, Ingo Oeser wrote:
>
> > Rik: Would you take patches for such a tradeoff sysctl?
>
> "such a tradeoff" ?
>
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT tradeoff
> they'd like
Thus spake Alan Cox ([EMAIL PROTECTED]):
> Can you boot a kernel without fdomain.c compiled in next
Yes, but I am too stupid: there were a faillure in my
patch-2.4.4-ac10.bz2, which is 0 bits so I have bunzip -c
patch-2.4.4-ac10.bz2|patch -p1 -s with an empty file :-((
That mean I compiled
On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> On Fri, 18 May 2001, Ingo Oeser wrote:
>
> > Rik: Would you take patches for such a tradeoff sysctl?
>
> "such a tradeoff" ?
>
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT
On Fri, 18 May 2001, Ingo Oeser wrote:
> Rik: Would you take patches for such a tradeoff sysctl?
"such a tradeoff" ?
While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make tunable and why...
I'm not against making things
On Fri, May 18, 2001 at 07:45:15PM +0200, Mike Galbraith wrote:
> Yes, ~exactly! I chose 30 tasks because they almost do (tool/userland
> dependant.. must recalibrate often) fit. The bitch is to get the vm
> to automagically detect the rss/cache munch tradeoff point without all
> the manual
On Fri, 18 May 2001, Rik van Riel wrote:
> On Fri, 18 May 2001, Mike Galbraith wrote:
> > On Thu, 17 May 2001, Rik van Riel wrote:
> > > On Thu, 17 May 2001, Mike Galbraith wrote:
> > >
> > > > Only doing parallel kernel builds. Heavy load throughput is up,
> > > > but it swaps too heavily.
On Fri, 18 May 2001, Mike Galbraith wrote:
> On Thu, 17 May 2001, Rik van Riel wrote:
> > On Thu, 17 May 2001, Mike Galbraith wrote:
> >
> > > Only doing parallel kernel builds. Heavy load throughput is up,
> > > but it swaps too heavily. It's a little too conservative about
> > > releasing
Thus spake Alan Cox ([EMAIL PROTECTED]):
> > SCSI subsystem driver Revision: 1.00
> > PCI: Found IRQ 11 for device 00:0b.0
> > Unable to handle kernel NULL pointer dereference at virtual address 000
> > printing eip:
>
> What scsi drivers do you have and which are on IRQ 11
I have two:
David Balazic <[EMAIL PROTECTED]> wrote:
> What old old binutils ?
> Isn't there a clear requirement for a minimum binutils version in
> Documentation/Changes ( or maybe it is README ... ) ?
Yes there is. From the Changes file:
o binutils 2.9.1.0.25 # ld -v
--
Alan Cox ([EMAIL PROTECTED]) wrote :
> >
> > gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
>-fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o apm.o apm.c
> > {standard input}: Assembler
Alan Cox ([EMAIL PROTECTED]) wrote :
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o apm.o apm.c
{standard input}: Assembler messages:
David Balazic [EMAIL PROTECTED] wrote:
What old old binutils ?
Isn't there a clear requirement for a minimum binutils version in
Documentation/Changes ( or maybe it is README ... ) ?
Yes there is. From the Changes file:
o binutils 2.9.1.0.25 # ld -v
--
André
Thus spake Alan Cox ([EMAIL PROTECTED]):
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 11 for device 00:0b.0
Unable to handle kernel NULL pointer dereference at virtual address 000
printing eip:
What scsi drivers do you have and which are on IRQ 11
I have two:
00:0b.0 SCSI
On Fri, 18 May 2001, Mike Galbraith wrote:
On Thu, 17 May 2001, Rik van Riel wrote:
On Thu, 17 May 2001, Mike Galbraith wrote:
Only doing parallel kernel builds. Heavy load throughput is up,
but it swaps too heavily. It's a little too conservative about
releasing cache now imho.
On Fri, 18 May 2001, Rik van Riel wrote:
On Fri, 18 May 2001, Mike Galbraith wrote:
On Thu, 17 May 2001, Rik van Riel wrote:
On Thu, 17 May 2001, Mike Galbraith wrote:
Only doing parallel kernel builds. Heavy load throughput is up,
but it swaps too heavily. It's a little too
On Fri, 18 May 2001, Ingo Oeser wrote:
Rik: Would you take patches for such a tradeoff sysctl?
such a tradeoff ?
While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make tunable and why...
I'm not against making things
On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
On Fri, 18 May 2001, Ingo Oeser wrote:
Rik: Would you take patches for such a tradeoff sysctl?
such a tradeoff ?
While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
Thus spake Alan Cox ([EMAIL PROTECTED]):
Can you boot a kernel without fdomain.c compiled in next
Yes, but I am too stupid: there were a faillure in my
patch-2.4.4-ac10.bz2, which is 0 bits so I have bunzip -c
patch-2.4.4-ac10.bz2|patch -p1 -s with an empty file :-((
That mean I compiled
On Fri, 18 May 2001, Rik van Riel wrote:
On Fri, 18 May 2001, Ingo Oeser wrote:
Rik: Would you take patches for such a tradeoff sysctl?
such a tradeoff ?
While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make
On Fri, 18 May 2001, Ingo Oeser wrote:
On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
such a tradeoff ?
While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make tunable and why...
Amount of pages
On Fri, 18 May 2001, Ingo Oeser wrote:
On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
On Fri, 18 May 2001, Ingo Oeser wrote:
Rik: Would you take patches for such a tradeoff sysctl?
such a tradeoff ?
While this sounds reasonable, I have to point out that
up to now
Anyway, the bug is in 2.4.4, not in 2.4.4-ac10: I am really sorry for
having loosing your time. With 2.4.4-ac9 with my fdomain, everything is
also working great ;-)
Great.
[Crosses another bug off]
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Fri, 18 May 2001, Mike Galbraith wrote:
While I'd love to have more control, I can't say I have a clear
picture of exactly how I'd like those knobs to look. I always
start out trying to get it to seek the right behavior.. :) and
end up fighting so many different fires I get lost in the
Hi,
On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
This is the core of why we cannot (IMHO) have a discussion
of whether a patch introducing new VM tunables can go in:
there is no clear overview of exactly what would need to be
tunable and how it would help.
It's worse than
1 - 100 of 145 matches
Mail list logo
