Re: oops in copy_page_rep()

On Tue, Jan 08, 2013 at 09:51:47AM -0800, Linus Torvalds wrote: > On Tue, Jan 8, 2013 at 9:37 AM, Andrea Arcangeli wrote: > > > > The reason it returned to userland and retried the fault is that this > > should be infrequent enough not to worry about it and this was > >

Re: a quest for a better scheduler

On Wed, Apr 04, 2001 at 03:34:22PM +0200, Ingo Molnar wrote: > > On Wed, 4 Apr 2001, Hubertus Franke wrote: > > > Another point to raise is that the current scheduler does a exhaustive > > search for the "best" task to run. It touches every process in the > > runqueue. this is ok if the runqueue

Re: a quest for a better scheduler

On Wed, Apr 04, 2001 at 10:03:10AM -0400, Hubertus Franke wrote: > I understand the dilemma that the Linux scheduler is in, namely satisfy > the low end at all cost. [..] We can satisfy the low end by making the numa scheduler at compile time (that's what I did in my patch at least). Andrea - To

x86_64 syscall numbering

I recently rewrote the syscall numbering for the x86_64 platform to optimize it at the cacheline usage level. If somebody wants to overview the numbering and give feedback or find something better that's welcome. We know we'll break the kernel API still at least once. I choosed the numbering in fu

Re: [Lse-tech] Re: a quest for a better scheduler

On Wed, Apr 04, 2001 at 09:39:23AM -0700, Kanoj Sarcar wrote: > example, for NUMA, we need to try hard to schedule a thread on the > node that has most of its memory (for no reason other than to decrease > memory latency). Independently, some NUMA machines build in multilevel > caches and local

Re: [Lse-tech] Re: a quest for a better scheduler

On Wed, Apr 04, 2001 at 09:50:58AM -0700, Kanoj Sarcar wrote: > > > > I didn't seen anything from Kanoj but I did something myself for the wildfire: > > > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.3aa1/10_numa-sched-1 > > > > this is mostly an userspace iss

Re: [Lse-tech] Re: a quest for a better scheduler

On Wed, Apr 04, 2001 at 10:49:04AM -0700, Kanoj Sarcar wrote: > Imagine that most of the program's memory is on node 1, it was scheduled > on node 2 cpu 8 momentarily (maybe because kswapd ran on node 1, other > higher priority processes took over other cpus on node 1, etc). > > Then, your patch

2 times faster rawio and several fixes (2.4.3aa3)

I merged some of SCT's fixes plus I fixed another couple of bugs and then I boosted the code to run faster. There's still room for improvements for example by using a ring of iobuf to walk pagetables and lock down pages for the next atomic I/O chunk while the I/O of the previous iobuf is in progre

Re: 2 times faster rawio and several fixes (2.4.3aa3)

On Fri, Apr 06, 2001 at 06:34:40PM +0200, Andrea Arcangeli wrote: > 2.4.3aa3 with rawio-1: > > root@alpha:/home/andrea > time ./rawio-bench > Opening /dev/raw1 > Allocating 50MB of memory > Reading from /dev/raw1 > Writing data to /dev/raw1 > > real0m5

Re: 2 times faster rawio and several fixes (2.4.3aa3)

On Fri, Apr 06, 2001 at 07:02:32PM +0200, Andi Kleen wrote: > On Fri, Apr 06, 2001 at 07:07:01PM +0200, Andrea Arcangeli wrote: > > However we can probably stay with the 512k atomic I/O otherwise the iobuf > > structure will grow again of an order of 2. With 512k of atomic

Re: 2 times faster rawio and several fixes (2.4.3aa3)

On Fri, Apr 06, 2001 at 07:36:21PM +0200, Andrea Arcangeli wrote: > 2/4Mbytes naturally aligned area). so probably I will take the vmalloc way As expected vmalloc additional 2 tlbs aren't visible in the numbers (that are mostly dominated by I/O anyways), I think it's the best solu

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

On Fri, Apr 06, 2001 at 07:27:24PM +0200, Maciej W. Rozycki wrote: > [..] You normally have > non-cached locations buffered (since you don't always need peripheral > device accesses to be posted immediately) and can force a writeback with a > memory barrier. [..] ev6 works the way you described A

Re: [PATCH] Re: softirq buggy

On Sun, Apr 08, 2001 at 11:35:36PM +0200, Manfred Spraul wrote: > I've attached a new patch: > > * cpu_is_idle() moved to > * function uninlined due to header dependencies > * cpu_is_idle() doesn't call do_softirq directly, instead the caller > returns to schedule() > * cpu_is_idle() exported fo

Re: [PATCH] Re: softirq buggy

On Mon, Apr 09, 2001 at 05:26:27PM +0200, Manfred Spraul wrote: > The return path to user space checks for pending softirqs. A delay of And it breaks the loop too if new softirq events become pending again in background. > 1/HZ is only possible if the cpu loops in kernel space without returning

Re: [PATCH] Re: softirq buggy

On Mon, Apr 09, 2001 at 09:48:02PM +0400, [EMAIL PROTECTED] wrote: > Hello! > > > Btw, you don't schedule the ksoftirqd thread if do_softirq() returns > > from the 'if(in_interrupt())' check. > > ksoftirqd will not be switched to before the first schedule > or ret form syscall, when softirqs wil

Re: Unresolved symbol in 2.4.4p1, ia32

On Mon, Apr 09, 2001 at 07:58:23PM +0100, Alan Cox wrote: > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o > > depmod: strstr > > > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o >

Re: Serial port latency

On Sun, Mar 25, 2001 at 11:10:14PM +, Pavel Machek wrote: > I've seen similar bugs. If you hook something on schedule_tq and forget > to set current->need_resched, this is exactly what you get. keventd fixes tq_scheduler case (tq_scheduler is dead). Andrea - To unsubscribe from this list: se

Re: BH_Req question

On Tue, Apr 10, 2001 at 01:12:02PM -0700, Rajagopal Ananthanarayanan wrote: > > Hi, > > It seems BH_Req is set on a buffer_head by submit_bh. > What part of the code unsets this flag during normal > operations? One path seems to be block_flushpage->unmap_buffer > ->clear_bit(BH_Req), but IIRC bl

Re: Bug in sys_sched_yield

On Wed, Apr 11, 2001 at 03:31:37PM -0400, Hubertus Franke wrote: > Below is the fix. correct. Could you also use cpu_curr(cpu) instead of the longer expression? (for the mainline it's only a beauty issue of course) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel"

O_DIRECT

I wrote the O_DIRECT zerocopy raw I/O support (dma from disk to the userspace memory through the filesystem). The patch against 2.4.4pre2 + rawio-3 is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/o_direct-1 Only ext2 is supported at the moment, but

Re: Linux 2.4.3-ac5

On Thu, Apr 12, 2001 at 07:17:26PM -0400, Greg Louis wrote: > On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote: > > > > 2.4.3-ac5 > > > o Fix rwsem compile problem (me) > > No such luck, I fear, at least not with egcs-2.91.66: > /usr/src/linux-2.4.3ac5/include/asm/rwse

generic rwsem [Re: Alpha "process table hang"]

On Fri, Apr 13, 2001 at 08:48:05AM -0500, Bob McElrath wrote: > Alan Cox [[EMAIL PROTECTED]] wrote: > > > (But since the X server shouldn't have the ability to corrupt the > > > kernel's process list, there has to be a problem in the kernel > > > somewhere) > > > > The X server has enough privile

Re: generic rwsem [Re: Alpha "process table hang"]

On Tue, Apr 17, 2001 at 05:59:13PM +0100, David Howells wrote: > Andrea, > > How did you generate the 00_rwsem-generic-1 patch? Against what did you diff? 2.4.4pre3 from kernel.org. > You seem to have removed all the optimised i386 rwsem stuff... Did it not work > for you? As said the design o

Re: generic rwsem [Re: Alpha "process table hang"]

On Tue, Apr 17, 2001 at 08:18:57PM +0100, D . W . Howells wrote: > Andrea, > > > As said the design of the framework to plugin per-arch rwsem implementation > > isn't flexible enough and the generic spinlocks are as well broken, try to > > use them if you can (yes I tried that for the alpha, it

Re: generic rwsem [Re: Alpha "process table hang"]

On Tue, Apr 17, 2001 at 11:29:23PM +0200, Christoph Hellwig wrote: > Yes! All the objects in export-objs only get additional depencies in > Rules.make - but if they do not get compiled at all that depencies won't > matter either. All other makefile work this way, btw. ok thanks for the confirm.

Re: generic rwsem [Re: Alpha "process table hang"]

On Tue, Apr 17, 2001 at 10:48:02PM +0100, D . W . Howells wrote: > I disagree... you want such primitives to be as efficient as possible. The > whole point of having asm/.h files is that you can stuff them full of > dirty tricks specific to certain architectures. Of course you always have t

Re: Is there a way to turn file caching off ?

On Wed, Apr 18, 2001 at 11:21:46AM -0700, David Schwartz wrote: > > > [..] If we assume the caching isn't helping [..] If you know kernel data cache doesn't help your workload at all then you want use O_DIRECT at least to save the CPU. You can run 2.4.4pre3aa3 or apply the rawio-3 patch

Re: generic rwsem [Re: Alpha "process table hang"]

. I wrote this rwsem stresser (if you have any bug in the rwsem this stresser will trigger it almost immediatly). /* * rw_semaphore benchmark (use with 2.4.3 or more recent kernels * that uses down_read() in the page fault and down_write() in mmap). * * Copyright (C) 2001 Andrea Arcangeli &l

Re: Kernel 2.5 Workshop RealVideo streams -- next time, please get better audio.

On Tue, Apr 17, 2001 at 10:46:20PM -0400, Albert D. Cahalan wrote: > support for NUMA hardware (it's not cache coherent) right now btw, there are three kind of NUMA systems: 1) cc-numa first citizens (wildfire alpha, future chips) 2) cc-numa second citizens (origin2k)

Re: generic rwsem [Re: Alpha "process table hang"]

On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote: > I'm at 2 days uptime now, and have not seen the process-table-hang. > Looks like this fixed it. Previously I would get a hang in the first > day or so. I'm using your alpha-numa-3 and rwsem-generic-4 against > 2.4.4pre3. good, than

Re: Kernel panics on raw I/O stress test

On Thu, Apr 19, 2001 at 09:01:53PM +0900, Takanori Kawano wrote: > > When I ran raw I/O SCSI read/write test with 2.4.1 kernel > on our IA64 8way SMP box, kernel paniced and following > message was displayed. Could you try again with 2.4.4pre4 plus the below patch? ftp://ftp.us.kerne

Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]

On Fri, Apr 20, 2001 at 12:28:09AM +0100, D . W . Howells wrote: > I benchmarked four different environments: > > (1) 2.4.4-pre3 + Andrea's generic rwsem patch > (2) 2.4.4-pre4 using XADD to implement the rwsems > (3) same as (2) but with a tweak to make rwsem_wake() less fair >

Re: Kernel panics on raw I/O stress test

On Fri, Apr 20, 2001 at 08:44:35PM +0900, Takanori Kawano wrote: > > > Could you try again with 2.4.4pre4 plus the below patch? > > > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/rawio-3 > > I suppose that 2.4.4-pre4 + rawio-3 patch still has SMP-unsafe

x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Fri, Apr 20, 2001 at 03:42:15AM +0200, Andrea Arcangeli wrote: > I'm uncertain if I should drop the list_empty() check from the fast path and if While dropping the list_empty check to speed up the fast path I faced the same complexity of the 2.4.4pre4 lib/rwsem.c and so before reinven

Re: [andrea@suse.de: Re: generic rwsem [Re: Alpha "process table hang"]]

On Fri, Apr 20, 2001 at 09:23:47AM +0100, David Howells wrote: > Andrea seems to have changed his mind on the non-inlining in the generic case. I changed my mind because if you benchmark the fast path you will do it without running out of icache (basically only down_* and up_* will be in the icac

Re: x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote: > I would suggest the following: > > - the generic semaphores should use the lock that already exists in the >wait-queue as the semaphore spinlock. Ok, that is what my generic code does. > - the generic semaphores should _not

Re: x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Sat, Apr 21, 2001 at 03:17:37PM +0100, Russell King wrote: > On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote: > > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote: > > > I would suggest the following: > > > > > > - the ge

Re: x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Sat, Apr 21, 2001 at 03:37:05PM +0100, [EMAIL PROTECTED] wrote: > Andrea Arcangeli writes: > > That it is allowed by my generic code that does spin_lock_irq in down_* and > > spin_lock_irqsave in up_* but it's disallowed by the wea

Re: x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Sat, Apr 21, 2001 at 03:37:42PM +0100, Russell King wrote: > On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote: > > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote: > > > I would suggest the following: > > > > > > - the ge

Re: [PATCH] rw_semaphores, optimisations

On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote: > This patch (made against linux-2.4.4-pre6) makes a number of changes to the > rwsem implementation: > > (1) Fixes a subtle contention bug between up_write and the down_* functions. > > (2) Optimises the i386 fastpath implementa

Re: [PATCH] rw_semaphores, optimisations

On Sun, Apr 22, 2001 at 09:07:03PM +0200, Andrea Arcangeli wrote: > On Sun, Apr 22, 2001 at 01:27:20AM +0100, D . W . Howells wrote: btw, I noticed I answered your previous email but for my benchmarks I really used your latest #try2 posted today at 13 (not last night a 1am), just to av

Re: [PATCH] rw_semaphores, optimisations

On Sun, Apr 22, 2001 at 11:52:29PM +0100, D . W . Howells wrote: > Hello Andrea, > > Interesting benchmarks... did you compile the test programs with "make > SCHED=yes" by any chance? Also what other software are you running? No I never tried the SCHED=yes. However in my modification of the rws

Re: [PATCH] rw_semaphores, optimisations

On Mon, Apr 23, 2001 at 03:04:41AM +0200, Andrea Arcangeli wrote: > that is supposed to be a performance optimization, I do the same too in my code. ah no I see what you mean, yes you are hurted by that. I'm waiting your #try 3 against pre6, by that time I hope to be able to make a ru

Re: generic rwsem [Re: Alpha "process table hang"]

On Mon, Apr 23, 2001 at 06:27:23PM -0500, Bob McElrath wrote: > Well, take that back, I just got it to hang. Again, this is 2.4.4pre3 > with alpha-numa-3 and rwsem-generic-4. I saw it upon starting mozilla. > I also saw some scary filesystem errors that may or may not be related: > Apr 23 18

Re: [PATCH] rw_semaphores, optimisations try #3

On Mon, Apr 23, 2001 at 09:35:34PM +0100, D . W . Howells wrote: > This patch (made against linux-2.4.4-pre6) makes a number of changes to the > rwsem implementation: > > (1) Everything in try #2 > > plus > > (2) Changes proposed by Linus for the generic semaphore code. > > (3) Ideas from A

rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Mon, Apr 23, 2001 at 11:34:35PM +0200, Andrea Arcangeli wrote: > On Mon, Apr 23, 2001 at 09:35:34PM +0100, D . W . Howells wrote: > > This patch (made against linux-2.4.4-pre6) makes a number of changes to the > > rwsem implementation: > > > > (1) Everyth

Re: [Semi-OT] Dual Athlon support in kernel

On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote: > Would the current state of athlon support be considered stable? yes. Andrea - 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://vge

Re: [Semi-OT] Dual Athlon support in kernel

On Tue, Apr 24, 2001 at 08:03:18AM +0200, Antwerpen, Oliver wrote: > I am also highly interested in information about dual Athlon (which > kernel/compiler/tools to use?), as we will get a dual Athlon sample before kernel >= 2.4.3 (better >= 2.4.4pre2 for other rasons) compiled for K7 and CONFIG_S

RAWIO-5 and O_DIRECT-3 updates

I fixed a new bug pointed out by Andrew and discussed on the kiobuf lis= t (thanks Andrew!) (lock_kiovec was not handling correctly a failed trylo= ckpage and could unlock pages locked by other people, not a big deal though as= such function is never called in the whole pre6 and I'm wondering if

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Tue, Apr 24, 2001 at 09:56:11AM +0100, David Howells wrote: > | +: "+m" (sem->count), "+a" (sem) ^^ I think you were comenting on the +m not +a ok > > >From what I've been told,

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Tue, Apr 24, 2001 at 11:25:23AM +0100, David Howells wrote: > > I'd love to hear this sequence. Certainly regression testing never generated > > this sequence yet but yes that doesn't mean anything. Note that your slow > > path is very different than mine. > > One of my testcases fell over on

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Tue, Apr 24, 2001 at 11:33:13AM +0100, David Howells wrote: > *grin* Fun ain't it... Try it on a dual athlon or P4 and the answer may come > out differently. compile with -mathlon and the compiler then should generate (%%eax) if that's faster even if the sem is a constant, that's a compiler is

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

There is a bug in both the C version and asm version of my rwsem and it is the slow path where I forgotten to drop the _irq part from the spinlock calls ;) Silly bug. (I inherit it also in the asm fast path version because I started hacking the same C slow path) I catched it now because it locks

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Tue, Apr 24, 2001 at 02:19:28PM +0200, Andrea Arcangeli wrote: > I'm starting the benchmarks of the C version and I will post a number update > and a new patch in a few minutes. (sorry for the below wrap around, just grow your terminal to read it stright)

Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

On Tue, Apr 24, 2001 at 02:07:47PM +0100, David Howells wrote: > It was my implementation that triggered it (I haven't tried it with yours), > but the bug occurred because the SUBL happened to make the change outside of > the spinlocked region in the slowpath at the same time as the wakeup routine

Re: Ingo's RAID patch for 2.2.18 final?

On Wed, Jan 24, 2001 at 04:05:12PM +0100, Sasi Peter wrote: > > This isn't obvious. Your working may not fit in cache and so the kernel > > understand it's worthless to swapout stuff to make space to a polluted > > cache. > > But your understanding agrees on that the larger chunks for each stream

Re: [ANNOUNCE] Kernel Janitor's TODO list

On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote: > Hi, > > On Mon, 29 Jan 2001, Andi Kleen wrote: > > > You can miss wakeups. The standard pattern is: > > > > get locks > > > > add_wait_queue(&waitqueue, &wait); > > for (;;) { > > if (condition you're wait

Re: [ANNOUNCE] Kernel Janitor's TODO list

On Mon, Jan 29, 2001 at 09:35:53PM +0100, Andi Kleen wrote: > On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote: > > You still miss wakeups. :) > > And there was another race in it, I know. The first __set_task_state > has to be set_task_state to get the right memory write order on SM

Re: Ingo's RAID patch for 2.2.18 final?

On Fri, Feb 16, 2001 at 10:53:51AM -0500, David Mansfield wrote: > This may be a bit OT, but when you say O_DIRECT, that implies that you > can pass that flag to open(2) and it will bypass the page cache, and yes. > read directly into user-space buffers (zero-copy IO)? Does this also yes. > b

Re: mke2fs and kernel VM issues

On Fri, Feb 16, 2001 at 04:44:48AM -0800, Theodore Y. Ts'o wrote: > Note that this only shows up when using mke2fs to create very large > filesystems, and you have relatively little memory. In this particular If you can reproduce the oom of mke2fs on recent 2.2.19pre, could you try again after a

Re: __lock_page calls run_task_queue(&tq_disk) unecessarily?

On Mon, Feb 19, 2001 at 11:05:23PM -0200, Marcelo Tosatti wrote: > --- linux/mm/filemap.c.orig Mon Feb 19 23:51:02 2001 > +++ linux/mm/filemap.c Mon Feb 19 23:51:33 2001 > @@ -611,11 +611,11 @@ > > add_wait_queue(&page->wait, &wait); > do { > - sync_page(page);

Re: __lock_page calls run_task_queue(&tq_disk) unecessarily?

On Tue, Feb 20, 2001 at 09:11:04AM -0800, Linus Torvalds wrote: > Even if it is wake-one, others may have claimed it before. There can be > new users coming in and doing a "trylock()" etc. > > NEVER *EVER* think that "exclusive wait-queue" implies some sort of > critical region protection. An exl

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote: > The reason why the IOP was changed was because the VG_CREATE ioctl now > depends on the vg_number in the supplied vg_t to determine which VG minor > number to use. The old interface used the minor number of the opened > device inod

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

On Tue, Feb 20, 2001 at 10:49:07PM +, Heinz Mauelshagen wrote: > > Hi all, > > a tarball of the Linux Logical Volume Manager 0.9.1 Beta 5 is available now at > > > > for download (Follow the "LVM download page" link). > > This release fixes several bugs. > See

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

On Wed, Feb 21, 2001 at 02:49:17PM +1100, Richard Gooch wrote: > You definately can mknod(2) on devfs. [..] So then why don't we simply create the VG ourself with the right minor number and use it as we do without devfs? We'll still have a global 256 VG limit this way but that's not a minor issue

Re: mke2fs + 8MB + 2.2.5 = hangs

On Wed, Feb 21, 2001 at 11:28:39PM +, Alan Cox wrote: > [..] only when creating _very_ large file > systems with little memory, where the write throttling may still need a bit > of work. I posted here a few days ago a little patch that is meant to address that. I didn't got any feedback on it

Re: ll_rw_block/submit_bh and request limits

On Thu, Feb 22, 2001 at 10:59:20AM -0800, Linus Torvalds wrote: > I'd prefer for this check to be a per-queue one. I'm running this in my tree since a few weeks, however I never had the courage to post it publically because I didn't benchmarked it carefully yet and I prefer to finish another thin

Re: ll_rw_block/submit_bh and request limits

On Thu, Feb 22, 2001 at 06:40:48PM -0200, Marcelo Tosatti wrote: > You want to throttle IO if the amount of on flight data is higher than > a given percentage of _main memory_. > > As far as I can see, your patch avoids each individual queue from being > bigger than the high watermark (which is

Re: ll_rw_block/submit_bh and request limits

On Thu, Feb 22, 2001 at 11:57:00PM +0100, Andrea Arcangeli wrote: > unsane to wait kupdate to submit 10G of ram to a single harddisk before > unplugging on a 30G machine. actually kupdate will unplug itself the queue but in theory it can grow the queue still up to such level after t

Re: ll_rw_block/submit_bh and request limits

On Thu, Feb 22, 2001 at 07:44:11PM -0200, Marcelo Tosatti wrote: > The global limit on top of the per-queue limit sounds good. Probably. > Since you're talking about the "total_ram / 3" hardcoded value... it > should be /proc tunable IMO. (Andi Kleen already suggested this) Yes, IIRC Andi also

Re: Linux 2.4.1-ac15

On Thu, Feb 22, 2001 at 10:29:58AM +, Alan Cox wrote: > > >We can take page faults in interrupt handlers in 2.4 so I had to use a > > >spinlock, but that sounds the same > > > > Umm? The above doesn't really make sense. > > > > We can take a page fault on the kernel region with the lazy pag

Re: Linux 2.4.1-ac15

On Fri, Feb 23, 2001 at 01:09:02PM -0800, Linus Torvalds wrote: > > > On Fri, 23 Feb 2001, Andrea Arcangeli wrote: > > > > I think that can't happen. Infact I think the whole section: > > > > pmd = pmd_offset(pgd, address); > >

Re: Linux 2.4.1-ac15

This new one should be better. Using the spinlock for the SMP serialization is ok because that's an extremely slow path. diff -urN -X /home/andrea/bin/dontdiff 2.4.2/arch/i386/mm/fault.c 2.4.2aa/arch/i386/mm/fault.c --- 2.4.2/arch/i386/mm/fault.c Thu Feb 22 03:44:53 2001 +++ 2.4.2aa/arch/i386/m

Re: ll_rw_block/submit_bh and request limits

On Sun, Feb 25, 2001 at 06:34:01PM +0100, Jens Axboe wrote: > Any reason why you don't have a lower wake-up limit for the queue? The watermark diff looked too high (it's 128M in current Linus's tree), but it's probably a good idea to resurrect it with a max difference of a few full sized requests

Re: NBD Cleanup patch and bugfix in ll_rw_blk.c

On Sun, Feb 25, 2001 at 07:57:29PM +, Steve Whitehouse wrote: > The bug fix in ll_rw_blk.c prevents hangs when using block devices which > don't have plugging functions, It looks the right fix (better than 2.4.0 that didn't had such bug but that was recalling the request_fn at every inserctio

Re: 64GB option broken in 2.4.2

On Mon, Feb 26, 2001 at 02:44:03AM -0600, Rico Tudor wrote: > > Hypthesis#2 The bounce buffer code in the Linus tree is known to be > > imperfect. Does 2.4.2ac3 do the same ? > > > No improvement. (In fact, 2.4.2ac3 breaks 3ware IDE RAID support.) The highmem changes in 2.4.2ac3 has a couple of

Re: [patch] highmem-2.4.2-A0

On Mon, Feb 26, 2001 at 09:44:16PM +0100, Ingo Molnar wrote: > -ac4. Differences: no need to complicate highmem.c with pool-fillup on > bootup. It will get refilled after the first disk-accesses anyway. I considered that, in practice it isn't going to make any difference, I _totally_ agree. But t

Re: Kernel is unstable

On Thu, Mar 01, 2001 at 12:16:08PM +0300, Ivan Stepnikov wrote: > if(p==malloc(block)){ Side note: I guess here you meant: if ((p = malloc(block)) { Make sure you catch when malloc returns null because of out of memory (the out of memory in your case happened i

Re: Kernel is unstable

On Thu, Mar 01, 2001 at 12:27:53PM +0200, Matti Aarnio wrote: > With malloc(1M): > > ... > 44089000-4418a000 rw-p 00:00 0 > 4418a000-4428b000 rw-p 00:00 0 > 4428b000-4438c000 rw-p 00:00 0 > 4438c000-4448d000 rw-p 00:00 0 > 4448d000-4458e000 rw-p 000

Re: Kernel is unstable

On Thu, Mar 01, 2001 at 03:35:12PM +0100, Andrea Arcangeli wrote: > From the above it's pretty obvious the clever vma merging is broken in 2.4. It's not broken, it's not there any longer as somebody dropped it between test7 and 2.4.2, may I ask why? Andrea - To unsubscribe fr

Re: Kernel is unstable

On Thu, Mar 01, 2001 at 06:20:49PM +, Alan Cox wrote: > > It's not broken, it's not there any longer as somebody dropped it between test7 > > and 2.4.2, may I ask why? > > Linus took it out because it was breaking things. If it happened to be buggy it didn't looked unfixable from a design st

Re: Kernel is unstable

On Fri, Mar 02, 2001 at 08:40:44AM +, David Howells wrote: > no matter how finely optimised the algorithm... But merging wouldn't be done > very often... only on memory allocation calls. Correct, it would happen only at mmap time of course. > Perhaps it'd be reasonable to only do VMA merging

Re: Kernel is unstable

On Thu, Mar 01, 2001 at 11:04:55AM -0800, David S. Miller wrote: > Linus didn't find it to be such a gain, and in fact the one > place that does gain from such merging (sys_brk()) does the > merging by hand :-) somewhere in either kernel or glibc we need to do the merging to avoid allocating new

Re: Printing to off-line printer in 2.4.0-prerelease

On Thu, Jan 04, 2001 at 02:09:56AM +0100, Peter Osterlund wrote: > should say that it is obsolete. I think obsolete means "you should never > ever have to use this stuff". Agreed. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: Printing to off-line printer in 2.4.0-prerelease

On Thu, Jan 04, 2001 at 09:27:51AM +, Tim Waugh wrote: > Believe it or not, there are some printers out there that wave > LP_POUTPA all over the place even when they're happy: they set > LP_PERRORP to mean 'happy', which is what the check is for. I remeber that too, that's why we still have L

Re: Printing to off-line printer in 2.4.0-prerelease

On Thu, Jan 04, 2001 at 11:20:27AM +, Tim Waugh wrote: > I wonder where the EIO is coming from though. Grep only shows up I think lp_check_status. } else if (!(status & LP_PSELECD)) { if (last != LP_PSELECD) { last = LP_PSELECD;

Re: Printing to off-line printer in 2.4.0-prerelease

On Thu, Jan 04, 2001 at 02:20:43PM +, Tim Waugh wrote: > to start with, fall into parport_write anyway (it will just time out As noted yesterday falling into parport_write will silenty lose data when the printer is off. If it's not feasible to make parport_write reliable against power-off pr

Re: [PATCH] dcache 2nd chance replacement

On Thu, Jan 04, 2001 at 01:00:28PM -0200, Rik van Riel wrote: > Other tasks tend not to stress the dcache like updatedb does, ^ > leading to the effect that updatedb can "flush out" the other > cached values faster than the other processes reference them.

Re: [PATCH] dcache 2nd chance replacement

On Thu, Jan 04, 2001 at 02:23:53PM -0200, Rik van Riel wrote: > > The dcache aging is mostly useful with _high_ VFS load like > > updatedb in background. The logic is the same of the VM aging > > (ask yourself when the VM aging is most useful: when there's > > high VM load, like a `cp /dev/zero .`

Re: [PATCH] dcache 2nd chance replacement

On Thu, Jan 04, 2001 at 02:59:49PM -0200, Rik van Riel wrote: > Unfortunately you seem to ignore my arguments, so lets I've not ignored them, as said they were either obviously wrong of offtopic. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a me

`rmdir .` doesn't work in 2.4

Hello Al, why `rmdir .` is been deprecated in 2.4.x? I wrote software that depends on `rmdir .` to work (it's local software only for myself so I don't care that it may not work on unix) and I'm getting flooded by failing cronjobs since I put 2.4.0 on such machine. `rmdir .` makes perfect sense

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 12:31:29PM -0500, Mohammad A. Haque wrote: > I fail to see why this is useful. you can't do anything in the directory > afterwards. > > bash# mkdir foobar > bash# cd foobar/ > bash# ls > bash# rmdir . > bash# touch foo > touch: foo: Operation not permitted > bash#

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote: > It's a hell of a pain wrt locking. You need to lock the parent, but it can This is a no-brainer and bad implementation, but shows it's obviously right wrt locking. (pseudocode, I ignored the uaccess details and all the other not re

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote: > Racy. Nonportable. Has portable and simple equivalent. Again, don't > bother with chdir at all - if you know the name of directory even > ../name will work. It's not about the current directory. It's about > the invalid last compone

Re: [PATCH,serious] Fix raid5 crashes in 2.4.0

On Mon, Jan 08, 2001 at 06:16:25PM +0100, Andi Kleen wrote: > > Hallo Linus, > > The following patch fixes an oops in 2.4.0 RAID5 initialisation when the kernel > was configured without CONFIG_X86_FXSR but is booted on a CPU supporting SSE. > The problem is that without the FXSR config the OSFX

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 09:56:18PM +0100, [EMAIL PROTECTED] wrote: > You think that it fails with EBUSY. That would be allowed but not required: > > [EBUSY]: The directory to be removed is currently in use by > the system or some process and the implementation > considers this t

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 04:08:58PM -0500, Alexander Viro wrote: > Andrea, fix your code. Linux-only stuff is OK when there is no BTW, "rmdir `pwd`" is not portable either. > portable way to achieve the same result. In your situation such way indeed > exists and is prefectly doable in userl

Re: Subtle MM bug

On Mon, Jan 08, 2001 at 02:00:19PM -0800, Wayne Whitney wrote: > I'd ask if this jives with your theory: if I configure the linux kernel > to be able to use 2GB of RAM, then the 870MB limit becomes much lower, to > 230MB. It's because the virtual address space for userspace tasks gets reduced fr

Re: `rmdir .` doesn't work in 2.4

On Mon, Jan 08, 2001 at 03:11:08PM -0700, Benson Chow wrote: > Not very portable at all... > > hpux = HP/UX 10.2 > > hpux:~$ mkdir foo > hpux:~$ cd foo > hpux:~/foo$ rmdir "`pwd`" > rmdir: /home/blc/foo: Cannot remove mountable directory > hpux:~/foo$ rmdir . > rmdir: cannot remove .. or . > hpu

Re: lvm 0.8 to 0.9 conversion?

On Mon, Jan 08, 2001 at 07:18:53PM +, Todd M. Roy wrote: > > I've been on vacation > > Nope, no snapshots. > > Well, I couldn't get my orginal volume group visible under both > lvm 0.8 and 0.9. I don't know why. So I grabbed a big empty hard disk, > created a new volume group that was

<    1   2   3   4   5   6   7   8   9   10   >