On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Please fix raid1 instead of making things worse.
huh, what do you mean?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Here is a patch to arch/i386/traps.c and arch/i386/signal.c which does
what you are suggesting, I believe.
I have tested this and it works fine for me. (Though I do also need
the patch which stores dr6 back into current-thread.debugreg[6]. That
is not included here since I submitted it
On Mon, Sep 25, 2000 at 03:02:58PM +0200, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
that is a showstopper bug. [...]
why?
Because as you said the machine can lockup when you run out of memory.
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
yet another elevator algorithm we need a squeaky clean VM balancer above
FYI: My current tree (based on 2.4.0-test8-pre5) delivers 16mbyte/sec
in the tiobench write test compared to clean 2.4.0-test8-pre5 that
delivers 8mbyte/sec
great! I'm
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
that is a showstopper bug. [...]
why?
Because as you said the machine can lockup when you run out of memory.
well, i think all kernel-space allocations have to be
On Mon, Sep 25, 2000 at 03:04:10PM +0200, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Please fix raid1 instead of making things worse.
huh, what do you mean?
I mean this:
while (!( /* FIXME: now we are rather fault tolerant than nice */
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
huh, what do you mean?
I mean this:
while (!( /* FIXME: now we are rather fault tolerant than nice */
this is fixed in 2.4. The 2.2 RAID code is frozen, and has known
limitations (ie. due to the above RAID1 cannot be used as a
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Is it safe to sleep on the waitqueue in the kmalloc fail path in
raid1?
yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
latencies)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, Sep 25, 2000 at 03:12:58PM +0200, Ingo Molnar wrote:
well, i think all kernel-space allocations have to be limited carefully,
When a machine without a gigabit ethernet runs oom it's userspace that
allocated the memory via page faults not the kernel.
And if the careful limit avoids the
On Mon, Sep 25, 2000 at 03:21:01PM +0200, Ingo Molnar wrote:
yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
latencies)
Very good! Many thanks Ingo.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hello to all,
I have one doubt and is as below.
Suppose say the two drivers driver1 and driver2 will install the ISR for a
particular interrupt, say UART0.
After some time the interrupt is generated. At this moment, which driver's
ISR is going to execute ?.
If driver1 ISR is get executed,
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
And if the careful limit avoids the deadlock in the layer above
alloc_pages, then it will also avoid alloc_pages to return NULL and
you won't need an infinite loop in first place (unless the memory
balancing is buggy).
yes i like this property
On Mon, 25 Sep 2000, Mahadev K Cholachagudda wrote:
Hello to all,
I have one doubt and is as below.
Suppose say the two drivers driver1 and driver2 will install the ISR for a
particular interrupt, say UART0.
After some time the interrupt is generated. At this moment, which driver's
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
latencies)
Very good! Many thanks Ingo.
this was actually coded/fixed by Neil Brown - so the kudos go to him!
Ingo
-
To unsubscribe from this list: send the line
On Mon, Sep 25, 2000 at 03:10:51PM +0200, Ingo Molnar wrote:
yep. But i dont understand why this makes any difference - the waitqueue
It makes a difference because your sleeping reads won't get the wakeup
even while they could queue their reserved read request (they have
to wait the FIFO to
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
- sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+ sync_page(page);
- run_task_queue(tq_disk);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+
Hi,
On Mon, Sep 25, 2000 at 04:02:30AM +0200, Andrea Arcangeli wrote:
On Sun, Sep 24, 2000 at 09:27:39PM -0400, Alexander Viro wrote:
So help testing the patches to them. Arrgh...
I think I'd better fix the bugs that I know about before testing patches that
tries to remove the
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Again: the bean counting and all the limit happens at the higher
layer. I shouldn't know anything about it when I play with the lower
layer GFP memory balancing code.
exactly, and this is why if a higher level lets through a GFP_KERNEL, then
it
On Mon, 25 Sep 2000, Mahadev K Cholachagudda wrote:
Hello to all,
I have one doubt and is as below.
Suppose say the two drivers driver1 and driver2 will install the ISR for a
particular interrupt, say UART0.
After some time the interrupt is generated. At this moment, which driver's
On Mon, 25 Sep 2000, Jens Axboe wrote:
The changes made were never half-done. The recent bug fixes have
mainly been to remove cruft from the earlier elevator and fixing a bug
where the elevator insert would screw up a bit. So I'd call that fine
tuning or adjusting, not fixing half-done
On Mon, Sep 25, 2000 at 03:57:31PM +0200, Ingo Molnar wrote:
i had yesterday - those were simple VM deadlocks. I dont see any deadlocks
Definitely. They can't explain anything about the VM deadlocks. I was
_only_ talking about the blkdev hangs that caused you to unplug the
queue at each
On Mon, Sep 25 2000, Robert Cohen wrote:
With kernel version 2.4.0-test9pre6 the results are as follows.
The test machine has 128 Megs of memory. The tests accesses 240 Megs of
files so that it can't fit in cache.
If I run it with 8 files of size 30 Megs:
[robert@test25 src]$ ./elv_test
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
I was _only_ talking about the blkdev hangs [...]
i guess this was just miscommunication. It never 'hung', it just performed
reads with 20k/sec or so. (without any writes being done in the
background.) A 'hang' for me is a deadlock or lockup, not a
On Mon, Sep 25 2000, Ingo Molnar wrote:
The changes made were never half-done. The recent bug fixes have
mainly been to remove cruft from the earlier elevator and fixing a bug
where the elevator insert would screw up a bit. So I'd call that fine
tuning or adjusting, not fixing half-done
On Sun, 24 Sep 2000, Ingo Molnar wrote:
i'm wondering about the following piece of code in refill_inactive():
if (current-need_resched (gfp_mask __GFP_IO)) {
__set_current_state(TASK_RUNNING);
schedule();
}
On Mon, Sep 25, 2000 at 03:49:52PM +0200, Jens Axboe wrote:
And a new elevator was introduced some months ago to solve this.
And now that I done some benchmark it seems the major optimization consists in
the implementation of the new _ordering_ algorithm in test2, not really from
the removal of
thanx for the thip with 2.2.17, it really solved my problem. but know i'm
getting
SIOCSIFSLAVE: invalid agrument.
error's when trying to ifenslave devices. i know that this may be the wrong
place for a discussion on bonding, but i hardly can find any help on this.
because it's quite urgent to
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
i had yesterday - those were simple VM deadlocks. I dont see any deadlocks
Definitely. They can't explain anything about the VM deadlocks. I was
_only_ talking about the blkdev hangs that caused you to unplug the
queue at each reschedule in tux
On Mon, Sep 25, 2000 at 04:04:14PM +0200, Ingo Molnar wrote:
exactly, and this is why if a higher level lets through a GFP_KERNEL, then
it *must* succeed. Otherwise either the higher level code is buggy, or the
VM balance is buggy, but we want to have clear signs of it.
I'm not sure if we
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
And a new elevator was introduced some months ago to solve this.
And now that I done some benchmark it seems the major optimization consists in
the implementation of the new _ordering_ algorithm in test2, not really from
the removal of the more
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
I'm not sure if we should restrict the limiting only to the cases that
needs them. For example do_anonymous_page looks a place that could
rely on the GFP retval.
i think an application should not fail due to other applications
allocating too much
On Mon, Sep 25, 2000 at 04:08:38PM +0200, Jens Axboe wrote:
The sg problem was different. When sg queues a request, it invokes the
request_fn to handle it. But if the queue is currently plugged, the
scsi_request_fn will not do anything.
That will explain it, yes. In the same way for
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
driver (and I very much hope that with EXCLUSIVE gone away and the
wait_on_* fixed those hangs will go away because I don't see anything else
wrong at this moment).
the EXCLUSIVE thing only optimizes the wakeup, it's not semantic! How
better is
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
The sg problem was different. When sg queues a request, it invokes the
request_fn to handle it. But if the queue is currently plugged, the
scsi_request_fn will not do anything.
That will explain it, yes. In the same way for correctness also
On Mon, Sep 25, 2000 at 04:11:34PM +0200, Jens Axboe wrote:
Interesting. I haven't done any serious benching with the CSCAN introduction
in elevator_linus, I'll try that too.
Only changing that the performance decreased reproducibly from 16 to 14
mbyte/sec in the read test with 2 threads.
So
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
snip
I talked with Alexey about this and it seems the best way is to have a
per-socket reservation of clean cache in function of the receive window. So we
don't need an huge atomic pool but we can have a special lru with an irq
spinlock that is
On Mon, 25 Sep 2000, Rik van Riel wrote:
2) you are right, we /can/ schedule when __GFP_IO isn't set, this is
mistake ... now I'm getting confused about what __GFP_IO is all
about, does anybody know the _exact_ meaning of __GFP_IO ?
__GFP_IO set to 1 means that the allocator can
On Mon, Sep 25, 2000 at 04:27:24PM +0200, Ingo Molnar wrote:
i think an application should not fail due to other applications
allocating too much RAM. OOM behavior should be a central thing and based
At least Linus's point is that doing perfect accounting (at least on the
userspace allocation
On Mon, Sep 25, 2000 at 04:29:42PM +0200, Ingo Molnar wrote:
There is no guarantee at all that the reader will win. If reads and writes
racing for request slots ever becomes a problem then we should introduce a
separate read and write waitqueue.
I agree. However here I also have a in flight
On Mon, Sep 25, 2000 at 04:18:54PM +0200, Jens Axboe wrote:
The scsi layer currently "manually" does a list_add on the queue itself,
which doesn't look too healthy.
It's grabbing the io_request_lock so it looks healthy for now :)
Andrea
-
To unsubscribe from this list: send the line
On Mon, Sep 25, 2000 at 11:26:48AM -0300, Marcelo Tosatti wrote:
This thread keeps freeing pages from the inactive clean list when needed
(when zone-free_pages zone-pages_low), making them available for
atomic allocations.
This is flawed. It's the irq that have to shrink the memory itself.
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
On Mon, Sep 25, 2000 at 03:02:58PM +0200, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
that is a showstopper bug. [...]
why?
Because as you said
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
the EXCLUSIVE thing was noticed by Dimitris i think, and it makes tons of
Actually I'm the one who introduced the EXCLUSIVE thing there and I audited
sorry - i said it was *noticed* by Dimitris. (and sent to l-k IIRC)
Ingo
-
To
On Sat, Sep 23, 2000 at 09:01:04PM -0500, [EMAIL PROTECTED] wrote:
Another interesting thing that I just noticed, I can still play music CD's in either
drive.
I am currently seeing the same behaviour. My machine is up for
42 days now. Kernel 2.2.16-3 (RH 6.2). I am quite sure
Because as you said the machine can lockup when you run out of memory.
well, i think all kernel-space allocations have to be limited carefully,
denying succeeding allocations is not a solution against over-allocation,
especially in a multi-user environment.
GFP_KERNEL has to be able to
On Mon, Sep 25, 2000 at 04:43:44PM +0200, Ingo Molnar wrote:
i talked about GFP_KERNEL, not GFP_USER. Even in the case of GFP_USER i
My bad, you're right I was talking about GFP_USER indeed.
But even GFP_KERNEL allocations like the init of a module or any other thing
that is static sized
On Mon, Sep 25, 2000 at 04:53:05PM +0200, Ingo Molnar wrote:
sorry - i said it was *noticed* by Dimitris. (and sent to l-k IIRC)
I didn't know.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Ingo Molnar wrote:
this is fixed in 2.4. The 2.2 RAID code is frozen, and has known
limitations (ie. due to the above RAID1 cannot be used as a swap-device).
Eh, just to be clear about this: does this apply to the RAID 0.90 code
as commonly patched in by RedHat? Should I instead use a swap
On Mon, 25 Sep 2000 [EMAIL PROTECTED] wrote:
this is fixed in 2.4. The 2.2 RAID code is frozen, and has known
limitations (ie. due to the above RAID1 cannot be used as a swap-device).
as commonly patched in by RedHat? Should I instead use a swap file
for a machine that should be
Hi,
The following patch allows an Alpha kernel to be built with a
cross-compiling toolchain as $(NM) and $(STRIP) do incorporate the
$(CROSS_COMPILE) prefix.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
GFP_KERNEL has to be able to fail for 2.4. Otherwise you can get
everything jammed in kernel space waiting on GFP_KERNEL and if the
swapper cannot make space you die.
if one can get everything jammed waiting for GFP_KERNEL, and not being
able to deallocate anything, thats a VM or
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
i think the GFP_USER case should do the oom logic within __alloc_pages(),
What's the difference of implementing the logic outside alloc_pages?
Putting the logic inside looks not clean design to me.
it gives consistency and simplicity. The
sorry: it was with iptables, not ipchains
=
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 /proc/sys/net/ipv4/ip_forward
=
g. everything else as in previous post
les
-
To unsubscribe from this list: send the line "unsubscribe
[reposted under __corrected__ subject line]
My linux box was set up for ipmasq with:
===
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 /proc/sys/net/ipv4/ip_forward
===
a windows box had been browsing the net through the linux box several
hours
On Mon, 25 Sep 2000, Alan Cox wrote:
Unless Im missing something here think about this case
2 active processes, no swap
#1#2
kmalloc 32K kmalloc 16K
OKOK
kmalloc 16K
On Sun, Sep 24, 2000 at 11:39:13PM -0300, Marcelo Tosatti wrote:
- Change kmem_cache_shrink to return the number of freed pages.
I did that too extending a patch from Mark. I also removed the first_not_full
ugliness providing a LIFO behaviour to the completly freed slabs (so
kmem_cache_reap
On Mon, Sep 25, 2000 at 04:16:56PM +0100, Alan Cox wrote:
Unless Im missing something here think about this case
2 active processes, no swap
#1#2
kmalloc 32K kmalloc 16K
OKOK
kmalloc 16K
I get these errors whenever I try to read data off of a new tape drive
that we got. (Onstream ADR-50)
st0: Error 2603 (sugg. bt 0x20, driver bt 0x26, host bt 0x3).
st0: Error on write filemark.
I'm not sure what they mean.. it's an external scsi device, and was
plugged in by someone else
On Mon, Sep 25, 2000 at 05:16:06PM +0200, Ingo Molnar wrote:
situation is just 1% RAM away from the 'root cannot log in', situation.
The root cannot log in is a little different. Just think that in the "root
cannot log in" you only need to press SYSRQ+E (or as worse +I).
If all tasks in the
On Mon, Sep 25, 2000 at 04:40:44PM +0100, Stephen C. Tweedie wrote:
Allowing GFP_ATOMIC to eat PF_MEMALLOC's last-chance pages is the
wrong thing to do if we want to guarantee swapper progress under
extreme load.
You're definitely right. We at least need the garantee of the memory to
allocate
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
Ingo's point is that the underlined line won't ever happen in the
first place
please dont misinterpret my point ...
Frankly, how often do we allocate multi-order pages? I've just made quick
statistics wrt. how allocation orders are distributed on
On Mon, Sep 25, 2000 at 04:42:49PM +0100, Stephen C. Tweedie wrote:
Progress is made, clean pages are discarded and dirty ones queued for
How can you make progress if there isn't swap avaiable and all the
freeable page/buffer cache is just been freed? The deadlock happens
in OOM condition (not
Hi!
This is all to protect those few poor 'administrators' who cannot keep
track of three separate files. We should not coddle such idiots, if
they cannot track 3 files they should not be configuring Linux.
Okay, so I'm idiot and I should not be configuring Linux?
No. I just have too
Hi,
On Mon, Sep 25, 2000 at 12:36:50AM +0200, bert hubert wrote:
On Mon, Sep 25, 2000 at 12:13:42AM +0200, Andrea Arcangeli wrote:
On Sun, Sep 24, 2000 at 10:43:03PM +0100, Stephen C. Tweedie wrote:
any form of serialisation on the quota file). This feels like rather
a lot of new and
On Mon, 25 Sep 2000, Stephen C. Tweedie wrote:
Sorry, but in this case you have got a lot more variables than you
seem to think. The obvious lock is the ext2 superblock lock, but
there are side cases with quota and O_SYNC which are much less
commonly triggered. That's not even starting to
Hi!
However, there's still a huge gap between the last progress() message and
availability of the frame buffer device. The simple console has the
advantage of outputing existing printk messages. (basically, it's a
console using prom_printf).
Something I forgot to mention about
On Mon, Sep 25, 2000 at 06:02:18PM +0200, Ingo Molnar wrote:
Frankly, how often do we allocate multi-order pages? I've just made quick
The deadlock Alan pointed out can happen also with single page allocation
if we in 2.4.x-current put a loop in GFP_KERNEL.
ie. 99.45% of all allocations are
On Mon, Sep 25, 2000 at 06:02:18PM +0200, Ingo Molnar wrote:
Frankly, how often do we allocate multi-order pages? I've just made quick
statistics wrt. how allocation orders are distributed on a more or less
typical system:
(ALLOC ORDER)
0: 167081
1: 850
2: 16
On Mon, 25 Sep 2000, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Stephen C. Tweedie wrote:
Sorry, but in this case you have got a lot more variables than you
seem to think. The obvious lock is the ext2 superblock lock, but
there are side cases with quota and O_SYNC which are much less
On Mon, 25 Sep 2000, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Rik van Riel wrote:
2) you are right, we /can/ schedule when __GFP_IO isn't set, this is
mistake ... now I'm getting confused about what __GFP_IO is all
about, does anybody know the _exact_ meaning of __GFP_IO ?
On Mon, 25 Sep 2000, Andi Kleen wrote:
An important exception in 2.2/2.4 is NFS with bigger rsize (will be fixed
in 2.5, but 2.4 does it this way). For an 8K r/wsize you need reliable
(=GFP_ATOMIC) 16K allocations.
the discussion does not affect GFP_ATOMIC - GFP_ATOMIC allocators *must*
On Mon, 25 Sep 2000, Alexander Viro wrote:
i'd suggest to simply BUG() in schedule() if the superblock lock is held
not directly by lock_super. Holding the superblock lock is IMO quite rude
anyway (for performance and latency) - is there any place where we hold it
for a long time and
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
On Mon, Sep 25, 2000 at 04:27:24PM +0200, Ingo Molnar wrote:
i think an application should not fail due to other applications
allocating too much RAM. OOM behavior should be a central thing and based
At least Linus's point is that doing perfect
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
ie. 99.45% of all allocations are single-page! 0.50% is the 8kb
You're right. That's why it's a waste to have so many order in the
buddy allocator. [...]
yep, i agree. I'm not sure what the biggest allocation is, some drivers
might use
On Mon, 25 Sep 2000, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
ie. 99.45% of all allocations are single-page! 0.50% is the 8kb
You're right. That's why it's a waste to have so many order in the
buddy allocator. [...]
yep, i agree. I'm not sure what the
On Mon, Sep 25, 2000 at 06:20:40PM +0200, Ingo Molnar wrote:
i only suggested this as a debugging helper, instead of the suggested
I don't think removing the superlock from all fs is good thing at this stage (I
agree with SCT doing it only for ext2 [that's what we mostly care about] would
be
On Mon, Sep 25, 2000 at 06:19:07PM +0200, Ingo Molnar wrote:
Another thing I would worry about are ports with multiple user page
sizes in 2.5. Another ugly case is the x86-64 port which has 4K pages
but may likely need a 16K kernel stack due to the 64bit stack bloat.
yep, but these cases
On Mon, 25 Sep 2000, Alan Cox wrote:
GFP_KERNEL has to be able to fail for 2.4. Otherwise you can get
everything jammed in kernel space waiting on GFP_KERNEL and if the
swapper cannot make space you die.
if one can get everything jammed waiting for GFP_KERNEL, and not being
able
On Mon, 25 Sep 2000, Rik van Riel wrote:
Hmmm, doesn't GFP_BUFFER simply imply that we cannot
allocate new buffer heads to do IO with??
No.
New buffer heads would be ok - recursion is fine in theory, as long as it
is bounded, and we might bound it some other way (I don't think we
_should_
On Mon, Sep 25, 2000 at 06:22:42PM +0200, Ingo Molnar wrote:
yep, i agree. I'm not sure what the biggest allocation is, some drivers
might use megabytes or contiguous RAM?
I'm not sure (we should grep all the drivers to be sure...) but I bet the old
2.2.0 MAX_ORDER #define will work for
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
On Mon, Sep 25, 2000 at 04:42:49PM +0100, Stephen C. Tweedie wrote:
Progress is made, clean pages are discarded and dirty ones queued for
How can you make progress if there isn't swap avaiable and all the
freeable page/buffer cache is just been
On Mon, Sep 25, 2000 at 06:18:17PM +0200, Andi Kleen wrote:
On Mon, Sep 25, 2000 at 06:19:07PM +0200, Ingo Molnar wrote:
Another thing I would worry about are ports with multiple user page
sizes in 2.5. Another ugly case is the x86-64 port which has 4K pages
but may likely need a 16K
On Mon, 25 Sep 2000, Ingo Molnar wrote:
On Mon, 25 Sep 2000, Andi Kleen wrote:
Another thing I would worry about are ports with multiple user page
sizes in 2.5. Another ugly case is the x86-64 port which has 4K pages
but may likely need a 16K kernel stack due to the 64bit stack bloat.
Hello,
I am not sure if this is kernel related or procps utils, but:
[root@castle log]# vmstat 1 5 | tail -6 | awk '{ print $16 }'
id
1
1
19884107 -- is this normal?!
1
0
Kernel 2.4.0-test2-ac2, procps-2.0.7.
Thanks.
--
// Andrius AdomaitisSistemu Administratorius
// [EMAIL PROTECTED]
On my /home partition, mkdir(2) is returning EIO on ext2fs for uid!=0.
Creating files with touch still works though. Persists after reboot,
forced e2fsck finds nothing wrong.
About to try test9-pre6 but thought I'd mention it.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Mon, 25 Sep 2000, Linus Torvalds wrote:
On Mon, 25 Sep 2000, Rik van Riel wrote:
Hmmm, doesn't GFP_BUFFER simply imply that we cannot
allocate new buffer heads to do IO with??
No.
New buffer heads would be ok - recursion is fine in theory, as long as it
is bounded, and we might
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
But I'd much prefer to pass not only the classzone from allocator
to memory balancing, but _also_ the order of the allocation,
and then shrink_mmap will know it doesn't worth to free anything
that isn't contigous on the order of the allocation
On Mon, 25 Sep 2000, Alexander Viro wrote:
On Mon, 25 Sep 2000, Ingo Molnar wrote:
yep, i agree. I'm not sure what the biggest allocation is, some drivers
might use megabytes or contiguous RAM?
Stupidity has no limits...
Blame the hardware designers... and give me my big allocations. :)
PCI: Failed to allocate resource 1 for Symbios Logic Inc. (formerly
NCR) 53c875
...
This is a PCI layout as reported by 'lspci -tv':
-[00]-+-0d.0-[01]--+-0a.0 Trident Microsystems 4DWave DX
|\-0d.0 Symbios Logic Inc. (formerly NCR) 53c875
...
Any ideas
On Mon, 25 Sep 2000, Linus Torvalds wrote:
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
But I'd much prefer to pass not only the classzone from allocator
to memory balancing, but _also_ the order of the allocation,
and then shrink_mmap will know it doesn't worth to free anything
that
On Mon, Sep 25, 2000 at 05:24:42PM +0100, Stephen C. Tweedie wrote:
Your other recent complaint, that newly-swapped pages end up on the
wrong end of the LRU lists and can't be reclaimed without cycling the
rest of the pages in shrink_mmap, is also cured in Rik's code, by
placing pages which
2 active processes, no swap
#1 #2
kmalloc 32K kmalloc 16K
OK OK
kmalloc 16K kmalloc 32K
block block
... and we get two
On Mon, 25 Sep 2000, Linus Torvalds wrote:
Yes, I'm inclined to agree. Or at least not disagree. I'm more arguing
that the order itself may not be the most interesting thing, and that
I don't think the balancing has to take the order of the allocation
into account - because it should be
On Mon, 25 Sep 2000, Linus Torvalds wrote:
Blaming the elevator is unfair and unrealistic. [...]
yep - and Jens i'm sorry about the outburst. Until a bug is found it's
unrealistic to blame anything.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, 25 Sep 2000, Alan Cox wrote:
yep, i agree. I'm not sure what the biggest allocation is, some drivers
might use megabytes or contiguous RAM?
Stupidity has no limits...
Unfortunately its frequently wired into the hardware to save a few cents on
scatter gather logic.
Since
On Mon, Sep 25, 2000 at 07:03:46PM +0200, Ingo Molnar wrote:
[..] __GFP_SOFT solves this all very nicely [..]
s/very nicely/throwing away lots of useful cache for no one good reason/
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, Sep 25, 2000 at 09:49:46AM -0700, Linus Torvalds wrote:
[..] I
don't think the balancing has to take the order of the allocation into
account [..]
Why do you prefer to throw away most of the cache (potentially at fork time)
instead of freeing only the few contigous bits that we need?
Stupidity has no limits...
Unfortunately its frequently wired into the hardware to save a few cents on
scatter gather logic.
Since when hardware folks became exempt from the rule above? 128K is
almost tolerable, there were requests for 64 _mega_bytes...
Most cheap ass PCI hardware
On Mon, Sep 25, 2000 at 07:05:02PM +0200, Ingo Molnar wrote:
yep - and Jens i'm sorry about the outburst. Until a bug is found it's
unrealistic to blame anything.
I think the only bug maybe to blame in the elevator is the EXCLUSIVE wakeup
thing (and I've not benchmarked it alone to see if it
Just got this one:
Sep 25 18:02:01 thecrypt kernel: kernel BUG at ll_rw_blk.c:711!
Sep 25 18:02:01 thecrypt kernel: invalid operand:
Sep 25 18:02:01 thecrypt kernel: CPU:0
Sep 25 18:02:01 thecrypt kernel: EIP:0010:[__make_request+161/1444]
Sep 25 18:02:01 thecrypt kernel: EFLAGS:
301 - 400 of 485 matches
Mail list logo