Hello,
as of the last stable version 2.4.18 VM management does not work for me
properly. I have Athlon system with 512MB ram, 2.4.18 kernel without any
additional patches.
I run following sequence of commands:
dd if=/dev/zero of=/tmp bs=1M count=512 &
find / -print &
{ wait a few seconds }
sync
at this point find stops completely or at least almost stops.
The same if I copy from /dev/hdf to /dev/hda. XOSVIEW shows only reading or only
writing (as bdflushd is flushing buffers). It never shows parallel reading and
writing. /proc/sys/* has default settings. I do not know the reason why i/o
system stops when bdflushd is flushing buffers nor reading can be done.
--
Luk?? Hejtm?nek
I do things like this regularly, and have been using kernels 2.4.10+ on
many types of boxen, but have yet to see this behavior. I've done this
same type of test with 16k blocks up to 10M, and not had this problem I
usually do test with regard to I/O on SCSI, but have tested on IDE,
since we use many IDE systems for developers. I found though, that using
something like LVM, and overwhelming it, causes bdflush to go crazy. I
can hit the wall you refer to then.When bdflushd is too busy...it does
in fact seem to *lock* the system, but of course..it's just bdflush
doing it's thing. If I modify the bdflush params..this causes things to
work just fine, at least, useable.
On Mon, 2002-07-08 at 17:11, Lukas Hejtmanek wrote:
> Hello,
>
> as of the last stable version 2.4.18 VM management does not work for me
> properly. I have Athlon system with 512MB ram, 2.4.18 kernel without any
> additional patches.
>
> I run following sequence of commands:
>
> dd if=/dev/zero of=/tmp bs=1M count=512 &
> find / -print &
> { wait a few seconds }
> sync
>
> at this point find stops completely or at least almost stops.
>
> The same if I copy from /dev/hdf to /dev/hda. XOSVIEW shows only reading or only
> writing (as bdflushd is flushing buffers). It never shows parallel reading and
> writing. /proc/sys/* has default settings. I do not know the reason why i/o
> system stops when bdflushd is flushing buffers nor reading can be done.
>
> --
> Luk?? Hejtm?nek
> -
> 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/
--
Austin Gonyou <[email protected]>
Yes, I know a few people that reports it works well for them. How ever for me
and some other do not. System is redhat 7.2, ASUS A7V MB, /dev/hda is on promise
controller. Following helps a lot:
while true; do sync; sleep 3; done
How did you modify the params of bdflush? I do not want to suspend i/o buffers
nor disk cache..
Another thing to notice, the X server has almost every time some pages swaped to
the swap space on /dev/hda. When bdflushd is flushing buffers X server stops as
has no access to the swap area during i/o lock.
On Mon, Jul 08, 2002 at 05:37:02PM -0500, Austin Gonyou wrote:
> I do things like this regularly, and have been using kernels 2.4.10+ on
> many types of boxen, but have yet to see this behavior. I've done this
> same type of test with 16k blocks up to 10M, and not had this problem I
> usually do test with regard to I/O on SCSI, but have tested on IDE,
> since we use many IDE systems for developers. I found though, that using
> something like LVM, and overwhelming it, causes bdflush to go crazy. I
> can hit the wall you refer to then.When bdflushd is too busy...it does
> in fact seem to *lock* the system, but of course..it's just bdflush
> doing it's thing. If I modify the bdflush params..this causes things to
> work just fine, at least, useable.
--
Luk?? Hejtm?nek
On 2002.07.09 Lukas Hejtmanek wrote:
>
>Yes, I know a few people that reports it works well for them. How ever for me
>and some other do not. System is redhat 7.2, ASUS A7V MB, /dev/hda is on promise
>controller. Following helps a lot:
>
>while true; do sync; sleep 3; done
>
>How did you modify the params of bdflush? I do not want to suspend i/o buffers
>nor disk cache..
>
>Another thing to notice, the X server has almost every time some pages swaped to
>the swap space on /dev/hda. When bdflushd is flushing buffers X server stops as
>has no access to the swap area during i/o lock.
>
>On Mon, Jul 08, 2002 at 05:37:02PM -0500, Austin Gonyou wrote:
>> I do things like this regularly, and have been using kernels 2.4.10+ on
>> many types of boxen, but have yet to see this behavior. I've done this
>> same type of test with 16k blocks up to 10M, and not had this problem I
>> usually do test with regard to I/O on SCSI, but have tested on IDE,
>> since we use many IDE systems for developers. I found though, that using
>> something like LVM, and overwhelming it, causes bdflush to go crazy. I
>> can hit the wall you refer to then.When bdflushd is too busy...it does
>> in fact seem to *lock* the system, but of course..it's just bdflush
>> doing it's thing. If I modify the bdflush params..this causes things to
>> work just fine, at least, useable.
>
Seriously, if you have that kind of problems, take the -aa kernel and use it.
I use it regularly and it behaves as one would expect, and fast.
And please, report your results...
--
J.A. Magallon \ Software is like sex: It's better when it's free
mailto:[email protected] \ -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-rc1-jam1, Mandrake Linux 8.3 (Cooker) for i586
gcc (GCC) 3.1.1 (Mandrake Linux 8.3 3.1.1-0.7mdk)
Here's the params I'm running...but it is with a -aa tree, just FYI.
vm.bdflush = 60 1000 0 0 1000 800 60 50 0
On Mon, 2002-07-08 at 17:50, Lukas Hejtmanek wrote:
> Yes, I know a few people that reports it works well for them. How ever for me
> and some other do not. System is redhat 7.2, ASUS A7V MB, /dev/hda is on promise
> controller. Following helps a lot:
>
> while true; do sync; sleep 3; done
>
> How did you modify the params of bdflush? I do not want to suspend i/o buffers
> nor disk cache..
>
> Another thing to notice, the X server has almost every time some pages swaped to
> the swap space on /dev/hda. When bdflushd is flushing buffers X server stops as
> has no access to the swap area during i/o lock.
>
> On Mon, Jul 08, 2002 at 05:37:02PM -0500, Austin Gonyou wrote:
> > I do things like this regularly, and have been using kernels 2.4.10+ on
> > many types of boxen, but have yet to see this behavior. I've done this
> > same type of test with 16k blocks up to 10M, and not had this problem I
> > usually do test with regard to I/O on SCSI, but have tested on IDE,
> > since we use many IDE systems for developers. I found though, that using
> > something like LVM, and overwhelming it, causes bdflush to go crazy. I
> > can hit the wall you refer to then.When bdflushd is too busy...it does
> > in fact seem to *lock* the system, but of course..it's just bdflush
> > doing it's thing. If I modify the bdflush params..this causes things to
> > work just fine, at least, useable.
>
> --
> Luk?? Hejtm?nek
--
Austin Gonyou <[email protected]>
On Tue, Jul 09, 2002 at 12:11:37AM +0200, Lukas Hejtmanek wrote:
>
> Hello,
>
> as of the last stable version 2.4.18 VM management does not work for me
> properly. I have Athlon system with 512MB ram, 2.4.18 kernel without any
> additional patches.
>
> I run following sequence of commands:
>
> dd if=/dev/zero of=/tmp bs=1M count=512 &
> find / -print &
> { wait a few seconds }
> sync
>
> at this point find stops completely or at least almost stops.
>
> The same if I copy from /dev/hdf to /dev/hda. XOSVIEW shows only reading or only
Wow, this is the same problem I was having! Checkout the thread 'sync
slowness. ext3 on VIA vt82c686b'. Some said it was my harddrive, but
this morning I noticed the problem is gone!
After I copy the file, sync returns right away. I'm running
2.4.19-rc1aa1 now.
--
L1: khromy ;khromy(at)lnuxlab.ath.cx
On Tue, Jul 09, 2002 at 12:58:16AM +0200, J.A. Magallon wrote:
>
> Seriously, if you have that kind of problems, take the -aa kernel and use it.
> I use it regularly and it behaves as one would expect, and fast.
> And please, report your results...
Great, -aa tree works perfectly for me. It was little bit tricky to get that
tree but now I think it works fine.
--
Luk?? Hejtm?nek
On Tue, Jul 09, 2002 at 12:58:16AM +0200, J.A. Magallon wrote:
> Seriously, if you have that kind of problems, take the -aa kernel and use it.
> I use it regularly and it behaves as one would expect, and fast.
> And please, report your results...
I've tried 2.4.19rc1aa2, it swaps even when I have 512MB ram and xcdroast with
scsi-ide emulation cd writer reports to syslog:
Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
(gfp=0x20/0)
Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
(gfp=0x20/0)
Jul 9 12:45:02 hell kernel: __alloc_pages: 2-order allocation failed
(gfp=0x20/0)
Jul 9 12:45:02 hell kernel: __alloc_pages: 1-order allocation failed
(gfp=0x20/0)
Jul 9 12:45:02 hell kernel: __alloc_pages: 0-order allocation failed
(gfp=0x20/0)
Am I something missing?
--
Luk?? Hejtm?nek
J.A. Magallon wrote:
> Seriously, if you have that kind of problems, take the -aa kernel and use it.
> I use it regularly and it behaves as one would expect, and fast.
> And please, report your results...
I run a 2 cpu server with 16 disks and around 5 megabytes of writes a
second. With plain 2.4.18 (using the feral.com qlogic driver) and 2GB
ram, this seemed okay. Upgrading to 4GB ram slowed the system down, and
normal shell commands became quite unresponsive with 4GB.
So we built a second server, with 2.4.19-pre9-aa2 using the qlogic
driver in the kernel. That driver needs patching, as it will otherwise
get stuck in a 'no handle slots' condition. Used a patch that I posted
to linux-scsi a while ago.
This combination works great so far. In the meantime, the 2.4.18 box has
been left running, but the load shoots up to 75 sometimes with no
apparent reason (the -aa2 box stays below a load of 3).
Once the 2.4.18 box was really wedged: load at 70, server process stuck.
I logged in and the system was very responsive, but in reponse to a
reboot the system just sat there.
So we're going with 2.4.19-pre9-aa2 for now. I don't yet understand the
-aa series, for example how 2.4.19-rc1-aa1 would relate to
2.4.19-pre9-aa2, so I'm a bit wary of just upgrading in the -aa series
right now.
Thomas
On Wed, Jul 10 2002, Thomas Tonino wrote:
> J.A. Magallon wrote:
>
> >Seriously, if you have that kind of problems, take the -aa kernel and use
> >it.
> >I use it regularly and it behaves as one would expect, and fast.
> >And please, report your results...
>
> I run a 2 cpu server with 16 disks and around 5 megabytes of writes a
> second. With plain 2.4.18 (using the feral.com qlogic driver) and 2GB
> ram, this seemed okay. Upgrading to 4GB ram slowed the system down, and
> normal shell commands became quite unresponsive with 4GB.
>
> So we built a second server, with 2.4.19-pre9-aa2 using the qlogic
> driver in the kernel. That driver needs patching, as it will otherwise
> get stuck in a 'no handle slots' condition. Used a patch that I posted
> to linux-scsi a while ago.
That's probably not just a mm issue, if you use stock 2.4.18 with 4GB
ram you will spend oodles of time bounce buffering i/o. 2.4.19-pre9-aa2
includes the block-highmem stuff, which enables direct-to-highmem i/o,
if you enabled the CONFIG_HIGHIO option.
In short, not an apples-to-apples comparison :-)
--
Jens Axboe
On Wed, 10 Jul 2002, Thomas Tonino wrote:
>...
> So we're going with 2.4.19-pre9-aa2 for now. I don't yet understand the
> -aa series, for example how 2.4.19-rc1-aa1 would relate to
> 2.4.19-pre9-aa2, so I'm a bit wary of just upgrading in the -aa series
> right now.
The -aa patches are usually against the most recent 2.4 kernel (they are
usually only available against one specific kernel), IOW the following are
increasing version numbers:
2.4.18-aa1
2.4.18-pre8-aa1
2.4.19-pre9-aa1
2.4.19-pre9-aa2
2.4.19-rc1-aa1 (rc = "release candidate")
2.4.19-aa1
2.4.20-pre1-aa1
> Thomas
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
Jens Axboe wrote:
> That's probably not just a mm issue, if you use stock 2.4.18 with 4GB
> ram you will spend oodles of time bounce buffering i/o. 2.4.19-pre9-aa2
> includes the block-highmem stuff, which enables direct-to-highmem i/o,
> if you enabled the CONFIG_HIGHIO option.
Indeed, highio seemed a feature I wanted, so I enabled it. But in the
'stuck' state on the 2 GB 2.4.18 machine, the load is 75 while there is
no disk activity according to iostat, but shells perform slowly anyway
and the CPU is idle. A reboot command doesn't work, but logging in over
ssh is still possible.
> In short, not an apples-to-apples comparison :-)
I agree a lot has changed in that kernel. And I wanted the O(1)
scheduler as well, as I expect a lot of processes on the server.
The 2.4.18 behaviour stays strange: the server has a fairly constant
workload, but the cpu load, normally averaging around 2, sometimes rises
to 75 in about an hour, and usually the load also winds down again.
None of the strange effects above have been noticed on 2.4.19-pre9-aa2.
BTW, the qlogic patch is great in preventing the handle slots issue.
Thomas
On Tue, Jul 09, 2002 at 12:48:08PM +0200, Lukas Hejtmanek wrote:
> On Tue, Jul 09, 2002 at 12:58:16AM +0200, J.A. Magallon wrote:
> > Seriously, if you have that kind of problems, take the -aa kernel and use it.
> > I use it regularly and it behaves as one would expect, and fast.
> > And please, report your results...
>
> I've tried 2.4.19rc1aa2, it swaps even when I have 512MB ram and xcdroast with
> scsi-ide emulation cd writer reports to syslog:
> Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
> (gfp=0x20/0)
> Jul 9 12:45:02 hell kernel: __alloc_pages: 3-order allocation failed
> (gfp=0x20/0)
> Jul 9 12:45:02 hell kernel: __alloc_pages: 2-order allocation failed
> (gfp=0x20/0)
> Jul 9 12:45:02 hell kernel: __alloc_pages: 1-order allocation failed
> (gfp=0x20/0)
> Jul 9 12:45:02 hell kernel: __alloc_pages: 0-order allocation failed
> (gfp=0x20/0)
>
> Am I something missing?
you may want to reproduce with vm_debug set to 1, but I'm pretty sure
it's a scsi generic issue, they are allocating ram with GFP_ATOMIC, and
they may eventually fail if kswapd cannot keep up with the other
GFP_ATOMIC allocations. They should use GFP_NOIO, with -aa it won't even
try to unmap pages. It will just try to shrink clean cache and it
should work fine for the above purpose where the allocation needs low
latency (the local_pages per-task ensures their work won't be stolen by
the GFP_ATOMIC users). I asked for that change some time ago but it
never happened apparently. However I assume the sr layer tried some more
after failing, sg has a quite large queue so some delay isn't fatal, and
you can probably safely ignore the above messages, they're just warnings
for you. nevertheless GFP_NOIO would make the allocations more reliable.
Andrea
On Wed, Jul 10, 2002 at 03:52:36PM +0200, Thomas Tonino wrote:
> Jens Axboe wrote:
>
> >That's probably not just a mm issue, if you use stock 2.4.18 with 4GB
> >ram you will spend oodles of time bounce buffering i/o. 2.4.19-pre9-aa2
> >includes the block-highmem stuff, which enables direct-to-highmem i/o,
> >if you enabled the CONFIG_HIGHIO option.
>
> Indeed, highio seemed a feature I wanted, so I enabled it. But in the
> 'stuck' state on the 2 GB 2.4.18 machine, the load is 75 while there is
> no disk activity according to iostat, but shells perform slowly anyway
I doubt the issue is highio here, the 75 load is probably because of 75
tasks deadlocked in D state, it's probably one of the many fixes in my
tree that avoided the deadlock for you.
If you provide a SYSRQ+T I would be more confortable though, so I can
tell you which of the fixes in my tree you need applied to mainline and
more important so I'm sure the problem is really just fixed in my tree.
I've no pending bugreport at the moment for -aa (the last emails for
rc1aa1 were all about acpi that didn't compile for smp, and I dropped it
in rc1aa2 until I get my poor broken laptop replaced).
thanks,
Andrea