On Thu, Nov 30, 2000 at 05:26:58PM -0500, Phillip Ezolt wrote:
> I'll give test12-pre3 a try and see if it fixes things.
test12-pre2 crashes at boot on my DS20. This patch workaround the problem
but I would be _very_ surprised if this is the right fix :) It's obviously not
meant for inclusion.
-
On Fri, Dec 01, 2000 at 02:56:19PM +0300, Ivan Kokshaysky wrote:
> Andrea, could you try this?
that's the right fix thanks (please send to Linus).
BTW, here is a preview of the asn SMP race fix for 2.4.x:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12-
On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote:
> Any ideas? (Or patches that I can test... ;-) )
miata seems to use cia southbridge so it should set an iommu direct mapping
large 2G. So it's maybe the second window between 1G and 2G that isn't set
correctly? Does the qlogic drive
On Wed, Nov 29, 2000 at 03:01:59PM -0700, Tom Rini wrote:
> As Dave Miller pointed out, DEV_MAC_HID sysctl conflicts with the RAID patches
That's right but OTOH I'd simply declare the sysctl-by-number interface dead
for new introduced sysctl. We need to preserve backwards compatibility of
course
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote:
> What data structure's would I look at? What should I investigate to
> verify this?
The relevant code is in arch/alpha/kernel/core_cia.c
> What would I have to do to test this? I have an ES40 & 3 miata's
Does the qlogic dr
On Fri, Dec 01, 2000 at 08:28:57AM -0800, Reto Baettig wrote:
> Is there any chance that we will see this patch as well as your other
> Alpha patches included in future 2.2.X and 2.4.X releases?
Yes, for 2.2.x I'm waiting 2.2.19pre, for 2.4.x as DaveM suggested we first
need to cleanup the interf
On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> |>
> |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> |> >
On Mon, Nov 27, 2000 at 02:34:45PM -0500, Richard B. Johnson wrote:
> The following shell-script shows that gcc-2.8.1 produces code with
> data allocations adjacent. However, they are reversed!
same with 2.95.* :).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Dec 01, 2000 at 10:19:44AM -0800, David S. Miller wrote:
>I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to
>avoid breakage of other archs but that should be probably removed:
>any CPU with per-CPU ASNs like alpha needs per-CPU per-MM context
>information t
On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> Also I believe linkers are allowed to arbitrarily reorder members in
> the data and bss sections. I could be wrong on this one though.
I'm not sure either, but we certainly rely on that behaviour somewhere.
Just to make an exampl
On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote:
> If you have two files:
> test1.c:
> int a,b,c;
>
> test2.c:
> int a,c;
>
> Which is _stronger_?
Those won't link together as they aren't declared static.
If they would been static they could be ordered file-per-file (note: I'
Side note: that could generate mem/io corruption only on headactive devices
(like IDE).
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 http://www.tux.org/lkml/
On Tue, Nov 21, 2000 at 05:28:40PM +0900, [EMAIL PROTECTED] wrote:
> @@ -47,6 +47,11 @@
> break;
> tmp->elevator_sequence--;
> }
> + if (entry == head) {
> + tmp = blkdev_entry_to_request(entry);
> + if (IN_ORDER(req, tmp))
> +
On Thu, Nov 23, 2000 at 01:01:25PM -0700, Jeff V. Merkey wrote:
> On Thu, Nov 23, 2000 at 12:01:35PM +, Stephen C. Tweedie wrote:
> > Hi,
> >
> > On Wed, Nov 22, 2000 at 11:54:24AM -0700, Jeff V. Merkey wrote:
> > >
> > > I have not implemented O_SYNC in NWFS, but it looks like I need to add
On Sat, Nov 18, 2000 at 07:46:29PM -0500, Alexander Viro wrote:
> ed fs/ext2/inode.c < /ext2_notify_change/
> /size >> 33/
> s/33/32/
> w
> q
> EOF
Good spotting but wrong fix.
Right fix for 2.2.x:
--- 33/fs/ext2/inode.c.~1~ Sun Nov 12 00:45:43 2000
+++ 33/fs/ext2/inode.c Sun Nov 19 02:02
On Mon, Nov 27, 2000 at 12:36:55PM -0500, Michael Meissner wrote:
> wrong to depend on two variables winding up in at adjacent offsets.
I'd like if it will be written explicitly in the specs that it's forbidden to
rely on that. I grepped the specs and I didn't find anything. So I wasn't sure
if I
On Wed, 30 Aug 2000, Alan Cox wrote:
>Please try 2.2.17pre20. THis has various vm and other fixes as well as an
>updated DAC960 driver
Note that the change to shrink_mmap to decrease the count in the while
clause, it's not fixing any deadlock.
To infinite loop the below conditions should be tru
On Tue, 29 Aug 2000, Richard Henderson wrote:
>Actually, if you'll look elsewhere you'll see that you cannot mismatch
>the two addresses and expect it to work on all implementations.
Good to know, thanks. I guessed the block size depends on the cacheline
size that's going to be more than 16bytes
The main features of 2.2.18pre2aa2 are:
o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert)
o Support for 2T of RAM on alpha (me)
o Improved VM for high end machines with enough ram and doing
heavy I/O under high memory pressure plus fixes
for the MAP
On Thu, 7 Sep 2000, Boszormenyi Zoltan wrote:
>It contains code in arch/i386/mtrr.c that looks pretty much like
>my "64 bit MTRR" patch that was posted on lkml some time last year
>and makes use of the full 36 bit MTRR address and size on Intel and
>44 bits on AMD Athlon. BTW my patch contained s
Hi Leonard,
this night I (hopefully) finally spotted and fixed a longstanding deadlock
that was hitting us on heavily loaded server running the DAC960.
The bug is present also in the earlier 2.2.x and 2.4.x and it's _not_ been
introduced with the DAC960 updates in 2.2.17.
In 2.4.x the SMP deadl
On Thu, 7 Sep 2000, Leonard N. Zubkoff wrote:
>I tried retrieving that file but was unsuccessful; is that the correct URL?
I guess I cut and pasted too much directories, sorry. I attached the file
since it's small.
>Is the fix simply moving the spin_unlock right before the call to
>add_wait_que
On Thu, 7 Sep 2000, Andi Kleen wrote:
>On Thu, Sep 07, 2000 at 09:00:29AM -0700, Leonard N. Zubkoff wrote:
>> WaitQueue_T WaitQueueEntry = { current, NULL };
>> add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
>> current->state = TASK_UNINTERRUPTIBLE;
>> spin_unlock(&io_req
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
>BTW Look also into asm-i386/bitops.h and dummy cast to some crap there.
>Are you impressed? 8)
Yep 8). If we add "memory" such stuff could be removed I think. As far I
can see the object of such stuff is to cause gcc to say `I'm too lazy to
see exactl
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Well, now GCC does CSE across "asm" and will eliminate memory loads,
What is "CSE"?
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 http://www.tux.org/
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Common Subexpression Elimination.
>
>If the compiler sees an expression equivalent to one it evaluated
>earlier, there is no need to evaluate it a second time.
>
>So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice.
I didn't know the na
Back in May I wrote a quite estensive documentation about all the
possible/best ways to debug the Linux Kernel for a talk/tranining that I
did in San Jose in May. I find now the time to clean it up and to upload
since I think it could result useful to everybody dealing with kernel
developement.
On Thu, 7 Sep 2000, Richard Henderson wrote:
>No it's not. We know how big the dummy_lock structure is, and
>so might "know" that it doesn't overlap with something else.
I guess Alexey point is that the current compiler doesn't notice that.
Andrea
-
To unsubscribe from this list: send the lin
Eric, sorry for the late reply.
On Thu, 7 Sep 2000, Eric Youngdale wrote:
>The oddness is this. We were observing stalls in the processing of
>commands that was traced to the fact that the queue had remained plugged
>for an excessive amount of time. The stalls last for about 5 seconds or
>
On Thu, 7 Sep 2000, Richard Henderson wrote:
>Perhaps. But that's not to say no future compiler won't.
I sure agree. That was my original concern w/o looking/knowing how smart
the current compiler was infact.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, 8 Sep 2000, Leonard N. Zubkoff wrote:
>I'm testing the modified driver out in the released 2.2.17 and getting the
>following messages while running mke2fs. Is this a known problem with 2.2.17,
>or something introduced by the change in waiting behavior?
It's known VM problem (unrelated t
On Fri, 8 Sep 2000, Tim Brunne wrote:
>*a silent hard disk hard disk is no longer feasible since kernel
>2.2.11*.
Try:
echo 40 500 64 256 0 >/proc/sys/vm/bdflush
once you want to return to the old behaviour:
echo 40 500 64 256 500 >/proc/sys/vm/bdfl
On Sat, 9 Sep 2000, Tim Brunne wrote:
>Thanks for this patch. But why hasn't it been included into
>the kernel earlier? Wouldn't be a combination of yours and my
It's basically included into 2.4.x.
>patch be the proper way? As far as I understand you switch
Your patch is sure fine. BTW, 2.4.x
On Sat, 9 Sep 2000, Richard Gooch wrote:
>at least a day, IMO. There's probably no reason it can't effectively
>be infinite. The kernel shouldn't be enforcing policy in this area.
Right. An embedded usage where there are no writeable blockdevices can
just set the interval to zero and avoid a sch
On Fri, 8 Sep 2000, Matthew Hawkins wrote:
>Something between bigmem and his big VM changes makes reiserfs
>uncompilable. [..]
It's due LFS. Chris should have a reiserfs patch that compiles on top of
2.2.18pre2aa2, right? (if not Chris, I can sure find it because the server
that was reproducing
On Mon, 11 Sep 2000, Chris Mason wrote:
>reiserfs-3.5.25, this patch. I tested against pre3-aa2.
BTW, pre3-aa2 means 2.2.18pre2aa2.bz2 applyed on top of 2.2.18pre3.
>Note, you might see debugging messages about items moving during
>copy_from_user. These are safe, but I'm leaving them in for
On Mon, 11 Sep 2000, Andi Kleen wrote:
>BTW, there is a another optimization that could help reiserfs a lot
>on SMP settings: do a unlock_kernel()/lock_kernel() around the user
>copies. It is quite legal to do that (you have to handle sleeping
>anyways in case of a page fault), and it allows CP
On Mon, 11 Sep 2000, Michael T. Babcock wrote:
>Considering there are a lot of people still using 2.0.x because they find it
>more stable than the 2.2.x series, doesn't it make sense to give this
>scalability to people who are already running SMP boxes on 2.2.x and who may
>decide to use ReiserFS
On Mon, 11 Sep 2000, Andi Kleen wrote:
>Given, but adding the unlock_kernel() does not really need much effort,
>it is a very cheap (programmer time wise) optimization.
Well, since there seems to be interest in this (and it's indeed very cheap
programmer time wise :) I will try to add such SMP o
On Wed, 6 Sep 2000, George Anzinger wrote:
>The times a kernel is not preemptable under this patch are:
>
>While handling interrupts.
>While doing "bottom half" processing.
>While holding a spinlock, writelock or readlock.
>
>At all other times the algorithm allows preemption.
So it can deadlock
On Mon, 11 Sep 2000, Rik van Riel wrote:
>Hmmm, maybe the Montavista people can volunteer to clean
>up all those places in the kernel code? ;)
That would be nice and welcome indipendently of the preemptible kernel
indeed. The right construct to convert that stuff is
spin_is_locked/spin_trylock (
On Tue, 12 Sep 2000, Rik van Riel wrote:
>The large IO delays I'm seeing in certain tests have
>been traced back to the /elevator/ code. I think I'll
Actually the elevator works as in 2.2.15 (before any fix). The latency
settings are too high. They should be around 250 for reads and 500 for
writ
On Tue, 12 Sep 2000, Alan Cox wrote:
>That code example can in theory deadlock without any patches if the CPU's
Woops I really meant:
while (test_and_set_bit(0, &lock));
/* critical section */
mb();
clear_bit(0, &lock);
Andrea
-
To unsubscribe from this list: s
On Tue, 12 Sep 2000, Rik van Riel wrote:
>We simply keep track of how old the oldest request
>in the queue is, and when that request is getting
>too old (say 1/2 second), we /stop/ all the others
Going in function of time is obviously wrong. A blockdevice can write 1
request every two seconds or
On Tue, 12 Sep 2000, Rik van Riel wrote:
>Uhmmm, isn't the elevator about request /latency/ ?
Yes, but definitely not absolute "time" latency.
How do you get a 1msec latency for a read request out of a blockdevice
that writes 1 request in 2 seconds? See?
That was one of the first issues I was
On Tue, 12 Sep 2000, Alan Cox wrote:
>Andrea - latency is time measured and perceived. Doing it time based seems to
>make reasonable sense. I grant you might want to play with the weighting per
When you have a device that writes a request every two seconds you still
want it not to seek all the t
On Tue, 12 Sep 2000, Rik van Riel wrote:
>We can already set different figures for different drives.
Right.
>Would it really be more than 30 minutes of work to put in
>a different request # limit for each drive that automatically
>satisfies the latency specified by the user?
Note that if you k
On Tue, 12 Sep 2000, Chris Evans wrote:
>like the task scheduler policies we have. For example, maybe we could flag
>a given process so that all it's I/O requests go to the head of the queue.
Yes. We can't do that at the moment because at the elevator layer we don't
know who is waiting for I/O c
On Tue, 12 Sep 2000, Rik van Riel wrote:
>But you don't. Transfer rate is very much dependant on the
>kind of load you're putting on the disk...
Transfer rate means `hdparm -t` in single user mode. Try it and you'll see
you'll get always the same result.
>Throughput really isn't that relevant h
On Tue, 12 Sep 2000, Rik van Riel wrote:
>Why do you always come up with impossible examples?
That's not impossible. impossible != unlikely.
A more regular case is when you have an extremely fast device, were a 1/2
second latency is too much, using 100msec could be just enough to provide
good t
On Tue, 12 Sep 2000, Jamie Lokier wrote:
>Sure the global system is slower. But the "interactive feel" is faster.
>If I type "find /" I want it to go quickly. But I still want Emacs to
You always want it to go quickly. But when you're in the blockdevice
layer you lost all the semantics of such
On Tue, 12 Sep 2000, Chris Evans wrote:
>the elevator code. Keep it to a queue management system, and suddenly it
>scales to slow or fast devices without any gross device-type specific
>tuning.
Yep, that was the object.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Tue, 12 Sep 2000, Alan Cox wrote:
>> That problem: the original elevator code did not schedule I/O particularly
>> fairly under certain I/O usage patterns. So it got fixed.
>
>No it got hacked up a bit.
Why do you say it's not been fixed? Can you still reproduce hangs long as
a write(2) can w
On Tue, 12 Sep 2000, Rik van Riel wrote:
>Also, this possibility is /extremely/ remote, if not
>impossible. Well, it could happen at one point in time,
It's not impossible. Think when you run a backup of you home directory
while you're listening mp3. Both `tar` and `xmms` will read the same file
On Tue, 12 Sep 2000, Martin Dalecki wrote:
>First of all: In the case of the mp3 player and such there is already a
>fine
>proper way to give it better chances on getting it's job done smooth -
>RT kernel sceduler priorities and proper IO buffering. I did something
>similiar
>to a GDI printer dr
On Wed, 13 Sep 2000, Stephen C. Tweedie wrote:
>You could use number-of-sectors, but that can't distinguish between
>random access and sequential access.
We actually use the number of `buffer headers` that enters the
ll_rw_block layer. (if all the fses have 4k blocksize it become the number
of s
On Wed, 13 Sep 2000, Alan Cox wrote:
>> Yes, but "how hard is it reasonable for the kernel to try" is based on
>> both items. A good first order approximation is number of requests.
>
>I must strongly disagree with that claim. A request could be 512 bytes or
>128K.
Current elevator account the
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
>The "large queue" goes against the whole point of this exercise - that
>is that if there are many items in the "queue" being sorted then
>unlucky requests can end up waiting a long time to get serviced.
Yep.
Andrea
-
To unsubscribe from this list:
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>Andrea Arcangeli wrote:
>>
>> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>>
>> >First of all: In the case of the mp3 player and such there is already a
>> >fine
>> >proper way to give it better chances
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>"Jeff V. Merkey" wrote:
>
>> lessons learned in live customer accounts. In NetWare, requests are
>> merged at A) the boundry between the File Cache and the I/O subsystem,
>> and B) in the drivers themselves and NOT THE ELEVATOR.
>
>Yes that's the prop
On Wed, 13 Sep 2000, Andi Kleen wrote:
>function that is called from the drivers as needed. For smart devices
>with very intelligent firmware you simply do not call it (assuming you
>have decently sized kiovec requests, with the current bh approach some
>premerging is probably always needed)
I
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>Yes seriously I would like to see it duplicated there. Becouse on this
>level it would be *far* simpler then on the generic level. And for
What do you mean with "simpler".
>a noabnormal configuration I guess the overall code size would
>be smaller the
On Wed, 13 Sep 2000, Giuliano Pochini wrote:
>I had a look at the new elevator. I hope I'm not wrong here... Requests
>are added to the queue scanning it starting from the tail. When the
>new request if found in-order with ad existing one, it's inserted int
Right so that it works in O(1) if you'
On Wed, 13 Sep 2000, Andi Kleen wrote:
>I guess it boils down to that the plugging (run_task(&tq_disc)) is overloaded
>in Linux. It does merging of requests which are the same anyways (=from the
>same operation in upper layers) and merging of requests that are unrelated.
&tq_disk doesn't merge a
On Thu, Sep 14, 2000 at 07:40:12PM +1000, Robert Cohen wrote:
> What I believe is happening is that the elevator isn't merging the
> requests properly.
> I think that this may be the same problem reported here
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0008.2/0389.html
The merging issu
> case-tags, there's at least a 51% probability I got it wrong; at least
Looks like you got it right ;)
I had another little compile problem here a patch:
diff -urN z/arch/alpha/vmlinux.lds 2.2.18pre6aa1/arch/alpha/vmlinux.lds
--- z/arch/alpha/vmlinux.ldsThu Sep 14 04:42:38 2000
+++ 2.2.18p
On Fri, Sep 15, 2000 at 05:34:23PM +0100, Alan Cox wrote:
>
> o Update NR_TASKS comment (Jarkko Kovala)
The only limit cames from the GDT that can handle 8192 entries (8 bytes each),
and each task needs two of them (one for LDT and one for the TSS) and the first
12 en
On Fri, Sep 15, 2000 at 09:08:25PM -0400, Giuliano Pochini wrote:
> Which is tightly dependent on the way we insert new rqs.
Sure the implementation would differ in function of the way we order the
requests during inserction, but the conceptual algorithm of the latency control
could remain the sa
This patch fixes two little bugs in the IA32 machine check handler, it's against
2.2.17pre7.
The first bug is that the MC0_MISC is at address 403H, the second is that
wmb() as implemented in IA32 doesn't serialize, a lock on the bus as
given from mb() will serialize instead.
--- 2.2.18pre7/arch/
On Sun, Sep 17, 2000 at 01:26:22AM +0200, Peter Osterlund wrote:
> Indeed, the elevator logic is somewhat flawed. There are two problems
> with the current code:
>
> 1. The test that decides if we have found a good spot to insert the
>current request doesn't handle the wraparound case correct
This patch fixes a SMP race in 2.2.18pre9:
--- IO-wait/include/linux/sched.h.~1~ Sun Sep 17 01:20:44 2000
+++ IO-wait/include/linux/sched.h Sun Sep 17 03:55:43 2000
@@ -499,7 +499,7 @@
#define __set_current_state(state_value) do { current->state = state_value; }
while (0)
#ifde
On Sun, Sep 17, 2000 at 12:11:40AM -0400, Albert D. Cahalan wrote:
> Umm, OK. I suppose that BSD prints this stuff? If so,
> somebody please send me an output sample and explanation
> so that I know where to put this stuff.
Some of the fields recently added to /proc/meminfo are very dependent on
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> If you have a better idea for memory management, I'd
> like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++ under low
memory scenario, right?
The only thing it can be a problem for an alternate VM if t
On Sun, Sep 17, 2000 at 10:53:17PM +0200, Peter Osterlund wrote:
> The test2 elevator (assuming it is the same as the test8 version) in the
Yes it's the same in such respect.
> infinite latency case will always send the request with the lowest sector
> number to the drive. (The request queue wil
On Sun, Sep 17, 2000 at 05:37:13PM -0300, Rik van Riel wrote:
> Sysrq-M displays the info for my VM too, but you'll have to
> admit that it isn't as useful as vmstat ;)
I agree about that info. That's an information not really relevant to the
internal of the memory balancing algorithm, but it's
On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
> Yes, I run my system with elvtune -r 250 -w 500.
Ok (sorry for asking, it was just to be sure).
> But even with -r 5 -w 5, I saw starvation. This, and
I'd call it "too high latency", not starvation. Well, strictly speaking it's
not
On Sun, Sep 17, 2000 at 04:39:35PM -0300, Marcelo Tosatti wrote:
>
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
>
>
>
> > If nobody does that before me I will try this "remeber last position of the
> > head" idea in my blkdev tree (there are many other
On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
> The new VM, as integrated in -test9-pre1, does the same thing,
Thanks for giving me some credit for my ideas.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
On Sun, Sep 17, 2000 at 03:36:04PM -0300, Rik van Riel wrote:
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> > On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> > > If you have a better idea for memory management, I'd
> > > like to hear it ;)
&g
On Sun, Sep 17, 2000 at 04:05:55PM -0300, Rik van Riel wrote:
> to be addressed ASAP. I've witnessed this starvation happen
> a couple of times and it's a really big problem...
Did you enabled the latency control as I suggested you a few days ago?
Andrea
-
To unsubscribe from this list: send the
On Sun, Sep 17, 2000 at 04:36:34PM -0300, Rik van Riel wrote:
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> > On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
> > > The new VM, as integrated in -test9-pre1, does the same thing,
> >
> > Thanks fo
On Sun, Sep 17, 2000 at 03:42:08PM -0400, Byron Stanoszek wrote:
> Not to be a bother, but I would still like to see a value or at least someone
> tell me what calculations I would need to do with the values listed in
> /proc/meninfo in order to determine the number of pages actually in-use by
> p
On Sun, Sep 17, 2000 at 08:57:00PM +0200, Peter Osterlund wrote:
> The new patch will obey the latency requirement but still keep disk
> seeks to a minimum. This makes it possible to use much smaller latency
Yes I agree that's a much nicer behaviour with strict latency requirements
(that's what 2
On Fri, Sep 08, 2000 at 01:41:05PM +0200, Jamie Lokier wrote:
> Casting via __dummy is there so that the "m" (or "=m") memory constraint
> will make that operand refer to the actual object in memory, and not a
> copy (in a different area of memory).
Are you really sure gcc could pass a copy even
On Tue, Sep 19, 2000 at 04:50:26AM -0300, Rik van Riel wrote:
> When the latency gets above 10 minutes, I'd call it starvation ;)
Me too, no argument about that.
> Not average latency no, but the starvation issue should be
> fixed...
2.2.18pre9aa1 delivers acceptable latency for me with the sam
On Tue, Sep 19, 2000 at 07:17:42AM -0300, Rik van Riel wrote:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
If you read the code you'll see that in his previous p
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> what I wanted to do in the new VM, except that I didn't
> see why we would want to restrict it to swap pages only?
You _must_ do that _only_ for the swap_cache, that's a specific issue of the
swap_cache during swapout (notenote: not
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote:
> One of the issues which seems to be affecting performance
> is the elevator starvation bug, though, so I'm not sure how
You are contraddicting yourself. If you decrease the latency (so if you fix the
starvation) the global disk throu
On Tue, Sep 19, 2000 at 08:30:05PM +0200, Peter Osterlund wrote:
> It is however possible to decide in O(1) time if the correct insertion
> point is at the end of the queue. We have to keep track of the point,
Right.
> [..] How long
> can the request queue be? Does it have a fixed upper size, or
On Tue, Sep 19, 2000 at 09:17:51PM +0200, Jens Axboe wrote:
> But there may be several p points in the queue, how are you going
> to keep track of all of them?
With the current elevator there should be only 1 p point, but with the
modification Peter suggested there can be more and we should track
On Tue, Sep 19, 2000 at 09:41:17PM +0200, Jens Axboe wrote:
> I don't see any reason why there can't be multiple p points in the current
> elevator.
Without the proposed modification after the last barrier in the queue all the
requests should be in order.
Andrea
-
To unsubscribe from this list:
On Tue, Sep 19, 2000 at 10:38:52PM +0200, Jens Axboe wrote:
> I haven't had a chance to really look at Peter's mods yet, but surely
> the current elevator can have many entries with 0 sequence. As an
> example, say the start sequence is 3 and we received request sector
> 10...1 in descending order
On Tue, Sep 19, 2000 at 11:09:47PM +0200, Peter Osterlund wrote:
> So that leaves two choices:
>
> 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second
>patch.)
We can try with 1. first.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, Sep 21, 2000 at 12:42:25AM +1100, Andrew Morton wrote:
> What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary if
> handle_sysrq() did a show_stack(0), which it doesn't, and probably
> should.
Yes, SYSRQ+P should definetly show the stack trace.
Andrea
-
To unsubscribe fro
On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
> On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> > > what I wanted to do in the new VM, except that I didn't
> > > see why we would w
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
> Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common. They're two completly orthogonal piece of code
(you can put LVM on top of MD but that's just because of the nice reentrance of
the blkdev API
On Thu, Sep 21, 2000 at 06:38:39PM -0500, Peter Samuelson wrote:
> Right. Functionally they overlap (lvm can do the equivalent of md
> linear) but structurally, the md drivers all operate under the md
lvm can do linear and raid0 (striping in two or more disks), and it supports
live snapshotting
On Fri, Sep 22, 2000 at 01:48:23PM -0700, Linus Torvalds wrote:
> (and I think LVM can do striping too). Yes, they have different
Yes LVM does striping too (it overlaps with raid0 functionality provided
by MD).
> It makes sense to group them together. Neither is a true hardware
> driver, and th
On Sat, Sep 23, 2000 at 01:34:33PM -0500, Peter Samuelson wrote:
> common association. It's a documentation issue as much as anything,
Agreed.
> and you've basically taken care of that in -pre6.
Looks fine to me too.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Wed, Oct 18, 2000 at 03:40:39PM +0100, Stephen C. Tweedie wrote:
> shm already does it: [..]
Right. Only the shared mappings and anonymoys memory need to be changed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
401 - 500 of 2012 matches
Mail list logo
