> > kmalloc 16K kmalloc 32K
> > block block
> >
> 2) set PF_MEMALLOC on the task you're killing for OOM,
>that way this task will either get the memory or
>fail (note that PF_MEMALLOC tasks don't wait)
Nobody is out of memory
> 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:
Enough that failures on this crashed older 2.2 kernels because the tcp code
ended up looping trying to get memory and the slab
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
> > 2 active processes, no swap
> >
> > #1 #2
> > kmalloc 32K kmalloc 16K
> > OK OK
> > kmalloc 16K kmalloc 32K
> > block block
> >
>
> ...
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
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
> > 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
>
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,
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
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
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.."
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
On Mon, 25 Sep 2000, Albert D. Cahalan wrote:
> > * Win32 access/share flags would have to be retained in the file
> > struct, and the inode struct would have to maintain a list of these.
>
> OK. Problem?
>
> The list would be NULL most of the time. If Linux apps start
> using this
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
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
Hi,
On Mon, Sep 25, 2000 at 01:41:37AM +0200, Andrea Arcangeli wrote:
>
> Since you're talking about this I'll soon (as soon as I'll finish some other
> thing that is just work in progress) release a classzone against latest's
> 2.4.x. My approch is _quite_ different from the curren VM. Current
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
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, 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
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
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
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, 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
David Howells writes:
> I'm still not keen on the idea, though... One of the things I'm trying to
> avoid is having to maintain a large patch to the kernel. I've done it before
Well, if this isn't worth doing right... Patch size is just something
you have to deal with. Hopefully you can get an
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, 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
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
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
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, 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
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:
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, 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
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
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
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,
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
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 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
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
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 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
>
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 05:26:59PM +0200, Ingo Molnar wrote:
>
> 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
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
[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
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
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
> > 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
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 +
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
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, 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
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
> > 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
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
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 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?
>
>
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
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
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
[My first linux crash in over 3 years]
My linux box was set up for ipmasq with:
===
/sbin/modprobe ip_masq_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
/sbin/ipchains -M -S 7200 10 160
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> At least Linus's point is that doing perfect accounting (at least on
> the userspace allocation side) may cause you to waste resources,
> failing even if you could still run and I tend to agree with him.
> We're lazy on that side and that's global
>
> On Mon, 25 Sep 2000, Andrzej Krzysztofowicz wrote:
> > I mean moving the __init database compiled into kernel (based on pci.ids) to
> > a separate module, which would be responsible for on-demand updating of text
> > information (i.e. replacing VID:DID numbers with text).
>
> In early
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
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> 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, 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
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.
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
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
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
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:
> > 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
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
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, 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
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
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]$
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, 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, 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
On Mon, Sep 25, 2000 at 03:39:51PM +0200, Ingo Molnar wrote:
> Andrea, if you really mean this then you should not be let near the VM
> balancing code :-)
What I mean is that the VM balancing is in the lower layer that knows anything
about the per-socket gigabit ethernet skbs limits, the limit
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
On Fri, 22 Sep 2000, Linus Torvalds wrote:
> On Fri, 22 Sep 2000, Molnar Ingo wrote:
> >
> > i'm still getting VM related lockups during heavy write load, in
> > test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
> > last VM related fix-patch, correct?). Here is a histogram
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> - sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> + sync_page(page);
> - run_task_queue(_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, 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:
> > 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
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
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
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,
The cciss driver is for our next generation of array controllers.
Besides adding the complexity of a single driver, there is also a question
of regression testing a single driver. The cpqarray driver has support for
all our controllers back to the EISA based controllers.
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
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, 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, 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
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 */
101 - 200 of 485 matches
Mail list logo
