On Tue, Dec 19, 2000 at 09:42:05AM +0100, Mikulas Patocka wrote:
> Failing getblk would likely introduce filesystem corruption. Look at
> getblk in 2.0 - when allocating new page fails it tries to reuse existing
> clean buffers or wakes up bdflush and waits until it writes them. This is
> the righ
On Tue, Dec 19, 2000 at 10:08:27AM -0500, Mike Black wrote:
> Rebooting this machine to 2.2.17-RAID works just fine
Which RAID patch are you using against 2.2.17 exactly? Also make sure you're
using exactly the same kernel configuration of 2.2.17-RAID.
> Might there be a problem with RAID5 as ro
On Sat, Dec 16, 2000 at 07:11:47PM +, Alan Cox wrote:
> o E820 memory detect backport from 2.4(Michael Chen)
It's broken, it will crash machines:
for (i = 0; i < e820.nr_map; i++) {
unsigned long start, end;
/* RAM? */
if (e
On Thu, Dec 21, 2000 at 01:57:15AM +1100, Andrew Morton wrote:
> If a task is on two waitqueues at the same time it becomes a bug:
> if the outer waitqueue is non-exclusive and the inner is exclusive,
Your 2.2.x won't allow that either. You set the `current->task_exclusive = 1'
and so you will ge
On Wed, Dec 20, 2000 at 03:48:06PM -0200, Rik van Riel wrote:
> On Wed, 20 Dec 2000, Andrea Arcangeli wrote:
> > On Thu, Dec 21, 2000 at 01:57:15AM +1100, Andrew Morton wrote:
> > > If a task is on two waitqueues at the same time it becomes a bug:
> > > if the outer wai
On Thu, Dec 21, 2000 at 09:38:43PM +1100, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> >
> > The fact you could mix non-exclusive and exlusive wakeups in the same waitqueue
> > was a feature not a misfeature. Then of course you cannot register in two
> > waitqueue
On Thu, Dec 21, 2000 at 03:07:08PM -0200, Rik van Riel wrote:
> c) will also implement a) in an obviously right and simple way.
So go ahead. If you think that's so simple and obviously right you can post
here a patch here against 2.2.19pre2 that implements C) to show real facts.
My B is here:
On Wed, Dec 20, 2000 at 02:28:58PM +0100, Andrea Arcangeli wrote:
> I was in the process of fixing this (I also just backported the thinkpad
> %edx clobber fix), but if somebody is going to work on this please let
> me know so we stay in sync.
Ok this should fix the e820 memory
On Fri, Dec 22, 2000 at 06:33:00PM +1100, Andrew Morton wrote:
> add_waitqueue_exclusive() and TASK_EXCLUSIVE, add a
There's no add_waitqueue_exclusive in my patch.
> Except for this bit, which looks slightly fatal:
>
> /*
> * We can drop the read-lock early if this
> *
On Sat, Dec 23, 2000 at 12:00:27AM +1100, Eyal Lebedinsky wrote:
> Linus Torvalds wrote:
> > - pre4:
> >- Andrea Arkangeli: update to LVM-0.9
>
> gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stac
On Fri, Dec 22, 2000 at 03:31:45PM +0100, Andrea Arcangeli wrote:
> On Sat, Dec 23, 2000 at 12:00:27AM +1100, Eyal Lebedinsky wrote:
> > Linus Torvalds wrote:
> > > - pre4:
> > >- Andrea Arkangeli: update to LVM-0.9
> >
> > gcc -D__KERNEL__ -I/usr/loc
On Fri, Dec 22, 2000 at 03:47:57PM +0100, Matthias Andree wrote:
> I suspect that these patches are mutually incompatible.
did you checked that there are no rejects after patching :)
> Could somebody please have a look at this? I will test or provide more
> information as requested.
Where's ser
On Fri, Dec 22, 2000 at 04:01:50PM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 22, 2000 at 03:31:45PM +0100, Andrea Arcangeli wrote:
> > On Sat, Dec 23, 2000 at 12:00:27AM +1100, Eyal Lebedinsky wrote:
> > > Linus Torvalds wrote:
> > > > - pre4:
> > > >
On Fri, Dec 22, 2000 at 05:07:27PM +0100, Arjan van de Ven wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Linus Torvalds wrote:
> >> - pre4:
> >>- Andrea Arkangeli: update to LVM-0.9
>
> > lvm.c: In function `lvm_do_create_proc_entry_of_lv':
>
> [snip]
>
> Hi,
>
> The patch below
On Fri, Dec 22, 2000 at 05:01:02PM +, Stephen Torri wrote:
> concerned. The module I am using is tulip_cb.
upgrade to latest pcmcia package on sourceforge.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please re
On Sat, Dec 23, 2000 at 05:56:42PM +1100, Andrew Morton wrote:
> If we elect to not address this problem in 2.2 and to rely upon the network
I see. There are two races:
1) race inside __wake_up when it's run on the same waitqueue: 2.2.19pre3
is affected as well as 2.2.18aa2, and 2.4
On Sat, Dec 23, 2000 at 02:24:39PM -0500, Todd M. Roy wrote:
>
> Now that in 2.4.0-test12-pre4, lvm 0.9 has replaced 0.8, is it possible
> to do a conversion of lvm created physical volumes, volume groups
> and logical volumes from 0.8 to 0.9?
on-disk format isn't changed so no conversion is nee
On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 1) could be fixed trivially by making the waitqueue_lock a spinlock, but
> > this way doesn't solve 2). And if we solve 2) properly than 1) gets fixed as
BTW (follow up myself), real
On Sun, Dec 24, 2000 at 01:28:59PM +1100, Andrew Morton wrote:
> This could happen with the old scheme where exclusiveness
> was stored in the task, not the waitqueue.
>
> >From test4:
>
> for (;;) {
> __set_current_state(TASK_UNINTERRUPTIBLE | TASK_EXCLUSIVE);
> /*
On Sun, Dec 24, 2000 at 04:17:10PM +1100, Andrew Morton wrote:
> I was talking about a different scenario:
>
> add_wait_queue_exclusive(&q->wait_for_request, &wait);
> for (;;) {
> __set_current_state(TASK_UNINTERRUPTIBLE);
> /* WINDOW */
> sp
On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote:
> ack.
This patch against 2.2.19pre3 should fix all races. (note that wait->flags
doesn't need to be initialized in the critical section in test1X too)
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19p
On Mon, Dec 25, 2000 at 11:59:51PM +0100, Christoph Hellwig wrote:
> Hi Linus & Heinz,
>
> there has been some discussion about the LVM /proc #ifdefs in
> Linux 2.4.0-test13pre4 (LVM 0.9). How about just removing
> CONFIG_LVM_PROC_FS? - beople that use LVM and procfs usually do
> not care for th
On Mon, Dec 25, 2000 at 11:53:33PM +0100, Christoph Hellwig wrote:
> The first patch fixes that and the second changes the toplevel Makefile
> to search only the kernel and gcc (for stdarg.h) includes to prevent such
> accidents.
Looks fine, thanks.
Andrea
-
To unsubscribe from this list: send t
On Tue, Dec 26, 2000 at 12:32:44AM +0100, Andrea Arcangeli wrote:
> On Mon, Dec 25, 2000 at 11:53:33PM +0100, Christoph Hellwig wrote:
> > The first patch fixes that and the second changes the toplevel Makefile
> > to search only the kernel and gcc (for stdarg.h) includes
On Wed, Dec 27, 2000 at 11:29:06AM +1100, Andrew Morton wrote:
> - Got rid of all the debugging ifdefs - these have been folded into
> wait.h
Why? Such debugging code is just disabled so it doesn't get compiled in, but if
somebody wants he can enable it changing the #define in the sources to ca
On Wed, Dec 27, 2000 at 01:57:12PM +1100, Andrew Morton wrote:
> Oh, it's all still there, but it's now all in the header file:
>
> #ifdef DEBUG
> #define foo() printk(stuff)
> #else
> #define foo()
> #endif
I intentionally didn't focused on such part of your patch because I understood
from the
On Wed, Dec 27, 2000 at 10:45:29PM +1100, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> >
> >
> > Not a big deal but still I'd prefer the CONFIG_SMP #ifdef though, it looks even
> > more obvious that it's a compile check and at least in your usage I
On Wed, Dec 27, 2000 at 09:32:36AM -0800, Larry McVoy wrote:
> [..] You do
> pay a price for not sharing TLB entries if the OS is stupid (Linux' is
> not).
Even assuming all segments are attached at the same virtual address on all MM
(this can be enforced with MAP_FIXED of course), we can't use t
On Sat, Dec 23, 2000 at 04:29:19PM -0500, Todd M. Roy wrote:
> group is visible, and you just told meit should be, then I can just
> copy volumes over under test13-pre3 and destroy and recreate the
> first volume group.
Is it possible you had a snapshot in the volume group when you started
lvm 0.
On Wed, Nov 29, 2000 at 12:56:44PM +0100, [EMAIL PROTECTED] wrote:
>
>
> Hi,
> I experienced disk hangs with linux-2.4.0-test11 on S/390 and after
> some debugging I found the cause. It the new method of unplugging
> block devices that doesn't go along with the S/390 disk driver:
>
> /*
> * r
On Fri, Dec 29, 2000 at 02:32:32AM +0100, Jure Pecar wrote:
> Hi all,
>
> I'm expiriencing a problem with thttpd web server
> (www.acme.com/software/thttpd) on recent linux 2.2 kernels with Andrea's
> VM-global patches. Without the patch server runs normally with its usual
Before the -7 revision
On Fri, Dec 29, 2000 at 03:29:53AM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 29, 2000 at 02:32:32AM +0100, Jure Pecar wrote:
> > Hi all,
> >
> > I'm expiriencing a problem with thttpd web server
> > (www.acme.com/software/thttpd) on recent linux 2.2 kernels
On Fri, Dec 29, 2000 at 09:40:54AM +0100, Jure Pecar wrote:
> problem on a similary configured 2.2.17 with VM-global patch 3. gcc
Good. Can you try to reproduce with 2.2.19pre3? (if you absolutely need raid
0.90 you can try again with 2.2.19pre3aa3 after backing out 04_wake-one-3 that
introduces
On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote:
> This is one of the main thttpd design points: run in a select() loop. Since
> it is intended for mainly static workloads, it performs quite well...
It can't scale in SMP.
Andrea
-
To unsubscribe from this list: send the line "unsubsc
On Sun, Dec 24, 2000 at 04:40:09PM +0100, Andrea Arcangeli wrote:
> On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote:
> > ack.
>
> This patch against 2.2.19pre3 should fix all races. (note that wait->flags
> doesn't need to be initialized in the crit
On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote:
> Your cgi will keep the other CPU occupied, or run two of them. thttpd has
> superb scaling properties compared to say apache.
I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu
serving static data and it shou
On Fri, Dec 29, 2000 at 06:56:09PM +, Alan Cox wrote:
> Depends on memory bandwidth, [..]
BTW, it could as well use TCP_CORK + sendfile that will become truly zero copy
eventually.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Fri, Dec 29, 2000 at 11:29:12AM -0800, Matt Liotta wrote:
> as such doesn't scale well with Linux 2.2 on a dual CPU machine. Our
> benchmarks show that we can handle more load on a single CPU machine then a
> dual CPU one with Linux 2.2. However, it is encouraging to see that the
If for what
On Thu, Dec 28, 2000 at 09:59:55PM -0800, David S. Miller wrote:
>
> "make check_asm" should fix it.
It doesn't work out of the box starting from pre3 because there are a
few fields in the task struct implemented this way:
struct list_head local_pages; int allocation_order, nr_local_pag
On Fri, Dec 29, 2000 at 08:21:12PM -0800, dean gaudet wrote:
> On Fri, 29 Dec 2000, Andrea Arcangeli wrote:
>
> > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote:
> > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has
> > > superb
On Fri, Dec 29, 2000 at 04:54:23PM -0500, Rafal Boni wrote:
> Now my box behaves much more reasonably... I'll just have to beat harder
> on it and see what happens.
Another thing: while writing to disk if you want low latency readers you can
do:
elvtune -r 1 /dev/hd[abcd]
The 1/2 second
On Sat, Dec 30, 2000 at 03:00:43PM -0700, Eric W. Biederman wrote:
> To get ENOSPC handling 99% correct all we need to do is decrement a counter,
> that remembers how many disks blocks are free. If we need a better
Yes, we need to add one field to the in-core superblock to do this accounting.
>
On Sat, Dec 30, 2000 at 08:50:52PM -0500, Alexander Viro wrote:
> And its meaning for 2/3 of filesystems would be?
It should stay in the private part of the in-core superblock of course.
> I _doubt_ it. If it is a pagecache issue it should apply to NFS. It should
> apply to ramfs. It should appl
On Sat, Dec 30, 2000 at 06:28:39PM -0800, Linus Torvalds wrote:
> There are only two real advantages to deferred writing:
>
> - not having to do get_block() at all for temp-files, as we never have to
>do the allocation if we end up removing the file.
>
>NOTE NOTE NOTE! The overhead for
On Sun, Dec 31, 2000 at 08:33:01AM -0800, Linus Torvalds wrote:
> By doing a better job of caching stuff.
Caching can happen after we are been slow and we waited for I/O synchronously
the first time (bread).
How can we optimize the first time (when the indirect blocks are out of buffer
cache) wi
On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
> The alpha systems I remember this problem on were all [..]
Yes the granularity issue has nothing to do with SMP (with preemptive kernel
it can trigger even without interrupts involved into the code). Also
CONFIG_SPACE_EFFICIENT loo
On Sun, Dec 31, 2000 at 06:36:50PM +0100, Andi Kleen wrote:
> AFAIK alpha has byte instructions now.
See other post. Only from ev6 (at least as far as gcc is concerned). I've an
userspace testcase here (it was originally an obscure alpha userspace MM
corruption bug report that I sorted out some t
On Thu, Dec 21, 2000 at 12:05:41PM +1100, Neil Brown wrote:
> So, I have started putting some patches together and they can be
> found at
> http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2/
I included the interesting ones in my tree.
Here two fixes against the vfs backport:
--- ./fs/nf
On Thu, Dec 21, 2000 at 12:18:56PM -0600, Thomas Dodd wrote:
> Andrea Arcangeli wrote:
> >
> > On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> > >
> > > > x()
> > > &
On Tue, Jan 02, 2001 at 11:02:41AM -0800, Linus Torvalds wrote:
> What does the system feel like if you just change the "sleep for bdflush"
> logic in wakeup_bdflush() to something like
>
> wake_up_process(bdflush_tsk);
> __set_current_state(TASK_RUNNING);
> current->policy |= S
On Tue, Jan 02, 2001 at 01:02:30PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 2 Jan 2001, Andrea Arcangeli wrote:
>
> > On Tue, Jan 02, 2001 at 11:02:41AM -0800, Linus Torvalds wrote:
> > > What does the system feel like if you just change the "sleep for bdflus
On Tue, Jan 02, 2001 at 12:09:32PM -0800, J Sloan wrote:
> # vgscan
> vgscan: error while loading shared libraries: vgscan: undefined symbol:
> lvm_remove_recursive
This looks like an userspace compilation/installation problem of the new lvm
tools. Make sure you removed the old (0.8*) shared libr
On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> Is there a better way to fix this problem?
It looks the simpler fix to me (main loop needs someway to handle errors
anyways) but ask Tim too.
Another way to fix it is to loop in interruptible mode inside lp_error waiting
the erro
On Wed, Jan 03, 2001 at 04:59:16PM -0200, Rik van Riel wrote:
> I know this probably isn't of any help under very low
> and very high loads, but it should provide a nice
> improvement under medium loads...
It should provide an improvement under high VFS load (lots of files lookedup
and not kept r
On Wed, Jan 03, 2001 at 05:47:39PM -0200, Rik van Riel wrote:
> Not really. Under very high VFS loads we'd just scan
> through the list twice and free the entries anyway.
You're obviously wrong.
The higher was the load, the faster your working set was getting dropped from
the dcache. (with the p
On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> off. Apparently the printer tells the computer it is OK to send data
> to it when it is off.
So then parport_write is probably buggy because it's losing data silenty while
the printer is off. So the below is probably a band aid.
On Wed, Jan 03, 2001 at 03:07:03PM -0600, Timur Tabi wrote:
> I'm experiencing some kind of memory leaks playing with ioremap and iounmap,
> and I've narrowed down the problem to iounmap refusing to unmap the memory that
> I just mapped. The line of code in question is
>
> if (!PageReserve
On Wed, Jan 03, 2001 at 09:09:01PM -0200, Rik van Riel wrote:
> Ever heard of slocate / updatedb ?
ever heard of somebody killing all other tasks while updatedb is running?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
On Thu, Jan 04, 2001 at 01:08:01AM +0100, Peter Osterlund wrote:
> What do you think about the following patch? It also works for all the
> tests mentioned in my previous message.
I'm worried somebody needed to disable LP_CAREFUL to print, probably it's not a
big deal to keep it. About the lp_wai
On Sun, Sep 24, 2000 at 09:34:43PM +0200, Ingo Molnar wrote:
> - do shrink_[d|i]cache_memory() even if !__GFP_IO. This improves balance.
It will deadlock. (that same mistake was dealdocking early 2.2.x too btw)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sun, Sep 24, 2000 at 10:26:11PM +0200, Ingo Molnar wrote:
> where will it deadlock?
ext2_new_block (or whatever that runs getblk with the superlock lock
acquired)->getblk->GFP->shrink_dcache_memory->prune_dcache->prune_one_dentry->dput->dentry_iput->iput->inode->i_sb->s_op->put_inode->ext2_di
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 interesting deadlocks to be introducing so late in
> 2.4. :-)
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, Sep 25, 2000 at 12:36:50AM +0200, bert hubert wrote:
> True. But they also appear to be found and solved at an impressive rate.
We're talking about shrink_[id]cache_memory change. That have _nothing_ to do
with the VM changes that happened anywhere between test8 and test9-pre6.
You were
On Sun, Sep 24, 2000 at 05:09:40PM -0700, Linus Torvalds wrote:
> [..] as with the
> shm_swap() thing this is probably something we do want to fix eventually.
both shm_swap and regular rw_swap_cache have the same deadlock problematic
w.r.t. __GFP_IO. We could do that on a raw device, but if we sw
On Sun, Sep 24, 2000 at 09:53:33PM -0300, Marcelo Tosatti wrote:
> Btw, why we need kmem_cache_shrink() inside shrink_{i,d}cache_memory ?
Because kmem_cache_free doesn't free anything. It only queues slab
objects into the partial and free part of the cachep slab queue (so that
they're ready to
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 superblock_lock at this stage. I guess you should
re-read the email from DaveM of two d
On Mon, Sep 25, 2000 at 12:13:08PM +0200, Ingo Molnar wrote:
>
> On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
>
> > Not sure if this is the right moment for those changes though, I'm not
> > worried about ext2 but about the other non-netoworked fses that nobody
>
On Mon, Sep 25, 2000 at 12:42:09PM +0200, Ingo Molnar wrote:
> believe could simplify unrelated kernel code significantly. Eg. no need to
> check for NULL pointers on most allocations, a GFP_KERNEL allocation
> always succeeds, end of story. This behavior also has the 'nice'
Sorry I totally disag
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
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 fau
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
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 rol
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 sh
On Mon, Sep 25, 2000 at 03:47:57PM +0200, Ingo Molnar wrote:
> this was actually coded/fixed by Neil Brown - so the kudos go to him!
Indeed :).
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 ht
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 resched
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
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 s
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 correct
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, 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 "unsubsc
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 itse
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 durin
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 05:10:43PM +0200, Ingo Molnar wrote:
> a SIGKILL? i agree with the 2.2 solution - first a soft signal, and if
> it's being ignored then a SIGKILL.
Actually we do the soft signal try (SIGTERM) only if the task was running
with iopl privilegies (and that means on alpha and o
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 re
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
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 sy
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
alloca
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
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: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 po
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 every
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
On Mon, Sep 25, 2000 at 01:22:40PM -0300, Rik van Riel wrote:
> whereas the old allocator could break down even when
> we still had enough swap free
As far I can see that's a bug that you hided introducing a deadlock.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-k
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 whic
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 [E
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
601 - 700 of 2012 matches
Mail list logo
