On Mon, Sep 25, 2000 at 07:05:02PM +0200, Ingo Molnar wrote:
> yep - and Jens i'm sorry about the outburst. Until a bug is found it's
> unrealistic to blame anything.
I think the only bug maybe to blame in the elevator is the EXCLUSIVE wakeup
thing (and I've not benchmarked it alone to see if it
On Mon, Sep 25, 2000 at 02:10:07PM -0300, Rik van Riel wrote:
> Not really. We could fix this by making the page freeing
> functions smarter and only free the pages we need.
That's what I proposed in first place infact.
To free large chunk of memory you may have to throw away lots of cache. We'r
On Mon, Sep 25, 2000 at 07:21:48PM +0200, bert hubert wrote:
> Ok, sorry. Kernel development is proceding at a furious pace and I sometimes
> lose track.
No problem :).
> I seem to remember that people were impressed by classzone, but that the
> implementation was very non-trivial and hard to g
On Mon, Sep 25, 2000 at 08:04:36PM +0200, Jan Niehusmann wrote:
> compiling md.c. But md.c is not needed for lvm, is it?
It is not needed, correct.
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 a
On Mon, Sep 25, 2000 at 07:06:57PM +0100, Stephen C. Tweedie wrote:
> Good. One of the problems we always had in the past, though, was that
> getting the relative aging of cache vs. vmas was easy if you had a
> small set of test loads, but it was really, really hard to find a
> balance that didn'
On Mon, Sep 25, 2000 at 10:52:08PM +0200, Peter Osterlund wrote:
> Do you know why? Is it because the average seek distance becomes
Good question. No I don't know why right now. I'll try again just to be 200%
sure and I'll let you know the results.
> smaller with your algorithm? (I later realize
On Mon, Sep 25, 2000 at 11:28:55PM +0200, Jens Axboe wrote:
> q->plug_device_fn(q, ...);
> list_add(...)
> generic_unplug_device(q);
>
> would suffice in scsi_lib for now.
It looks sane to me.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Mon, Sep 25, 2000 at 04:26:17PM -0300, Rik van Riel wrote:
> > > It doesn't --- that is part of the design. The vm scanner propagates
> >
> > And that's the inferior part of the design IMHO.
>
> Indeed, but physical page based aging is a definate
> 2.5 thing ... ;(
I'm talking about the fac
On Mon, Sep 25, 2000 at 08:54:57PM +0100, Stephen C. Tweedie wrote:
> OK, and here's another simple real life example. A 2GB RAM machine
> running something like Oracle with a hundred client processes all
> shm-mapping the same shared memory segment.
Oracle takes the SHM locked, and it will neve
On Mon, Sep 25, 2000 at 07:26:56PM -0300, Rik van Riel wrote:
> IMHO this is a minor issue because:
I don't think it's a minor issue.
If you don't have reschedule point in your equivalent of shrink_mmap and this
1.5G will happen to be consecutive in the lru order (quite probably if it's
been pag
On Tue, Sep 26, 2000 at 12:30:28AM +0200, Juan J. Quintela wrote:
> Which is completely wrong if the program uses _any not completely_
> unusual locality of reference. Think twice about that, it is more
> probable that you need more that 300MB of filesystem cache that you
> have an aplication tha
On Mon, Sep 25, 2000 at 03:30:10PM -0700, Linus Torvalds wrote:
> On Tue, 26 Sep 2000, Andrea Arcangeli wrote:
> >
> > I'm talking about the fact that if you have a file mmapped in 1.5G of RAM
> > test9 will waste time rolling between LRUs 384000 pages, while classzo
On Mon, Sep 25, 2000 at 04:18:13PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 26 Sep 2000, Andrea Arcangeli wrote:
> >
> > The machine will run low on memory as soon as I read 200mbyte from disk.
>
> So?
>
> Yes, at that point we'll do the LRU dance
On Tue, Sep 26, 2000 at 08:54:23AM +0200, Christoph Rohland wrote:
> "Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > On Mon, Sep 25, 2000 at 09:32:42PM +0200, Andrea Arcangeli wrote:
> >
> > > Having shrink_mmap that
On Tue, Sep 26, 2000 at 12:14:18AM +0200, Andrea Arcangeli wrote:
> On Mon, Sep 25, 2000 at 10:52:08PM +0200, Peter Osterlund wrote:
> > Do you know why? Is it because the average seek distance becomes
>
> Good question. No I don't know why right now. I'll try again j
On Tue, Sep 26, 2000 at 10:12:44AM -0700, Linus Torvalds wrote:
> It should probably just be a GFP_USER (ie not the GFP_KERNEL "try very
> hard").
GFP_KERNEL and GFP_USER have to try equally very hard until the machine runs
_truly_ out of memory.
When the machine runs truly out of memory I think
On Tue, Sep 26, 2000 at 06:20:47PM +0200, Christoph Rohland wrote:
> O.K. that sound more reasonable. I was reading image as program
> text... and a 1.5GB program text is a something I never have seen (and
> hopefully will never see :-)
:)
>From the shrink_mmap complexity of the algorithm point
On Tue, Sep 26, 2000 at 09:10:16PM +0200, Pavel Machek wrote:
> Hi!
> > > 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
On Tue, Sep 26, 2000 at 10:00:12PM +0200, Peter Osterlund wrote:
> Therefore, no matter what algorithm you use in elevator_linus() the total
> number of seeks should be the same.
It isn't. There's a big difference between the two algorithms and all your
previous emails was completly correct about
On Wed, Sep 27, 2000 at 10:11:43AM +0200, Christoph Rohland wrote:
> I just checked one oracle system and it did not lock the memory. And I
If that memory is used for I/O cache then such memory should released when the
system runs into swap instead of swapping it out too (otherwise it's not cache
On Wed, Sep 27, 2000 at 09:42:45AM +0200, Ingo Molnar wrote:
> such screwups by checking for NULL and trying to handle it. I suggest to
> rather fix those screwups.
How do you know which is the minimal amount of RAM that allows you not to be in
the screwedup state?
We for sure need a kind of cou
On Wed, Sep 27, 2000 at 06:56:42PM +0200, Christoph Rohland wrote:
> Yes, but how does the application detect that it should free the mem?
The trivial way is not to detect it and to allow the user to select how much
memory it will use as cache and to take it locked and then don't care (he will
ha
On Wed, Sep 27, 2000 at 12:25:44PM -0600, Erik Andersen wrote:
> Or sysinfo(2). Same thing...
sysinfo structure doesn't export the number of active pages in the system.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Thu, Sep 28, 2000 at 07:08:51AM -0300, Rik van Riel wrote:
> taking care of this itself. But this is not something the OS
> should prescribe to the application.
Agreed.
> (unless the SHM users tell you that this is the normal way
> they use SHM ... but as Christoph just told us, it isn't)
sh
On Thu, Sep 28, 2000 at 08:16:32AM -0300, Rik van Riel wrote:
> Andrea, I have the strong impression that your idea of
> memory balancing is based on the idea that the OS should
> out-smart the application instead of looking at the usage
> pattern of the pages in memory.
Not sure what you mean wi
On Thu, Sep 28, 2000 at 01:31:40PM +0200, Ingo Molnar wrote:
> if the shm contains raw I/O data, then thats flawed application design -
> an mmap()-ed file should be used instead. Shm is equivalent to shared
The DBMS uses shared SCSI disks across multiple hosts on the same SCSI bus
and synchroniz
On Thu, Sep 28, 2000 at 05:13:59PM +0200, Ingo Molnar wrote:
> Can anyone see any problems with the concept of this approach? This can be
It works only on top of a filesystem while all the checkpointing clever stuff
is done internally by the DB (infact it _needs_ O_SYNC when it works on the
fs).
On Fri, Sep 29, 2000 at 11:39:18AM -0300, Rik van Riel wrote:
> OK, good to see that we agree on the fact that we
> should age and swapout all pages equally agressively.
Actually I think we should start looking at the mapped stuff _only_ when the
I/O cache aging is relevant. If the I/O cache agin
On Wed, Sep 27, 2000 at 12:18:11PM +, Pavel Machek wrote:
> I want that machine! Hmm, would it fit in my room?
It depends on the size of the room of course, but it wouldn't fit in mine and
you also need 3phase electricity connection to have a chance to power it up :).
Pretty amazing. I ported
On Sat, Sep 30, 2000 at 02:58:35PM -0300, Rik van Riel wrote:
> Both the current code and classzone will need some adjustments
> to work fine (as in: reasonably efficient) with NUMA.
The exact thing I was talking about in my previous email is that in classzone
_all_ the cache lru are been intenti
On Sun, Oct 01, 2000 at 03:04:31AM -0400, Frank Davis wrote:
> Hello all,
> I've been going through the drivers/block code (almost done) and noticed the
>use of, eg.:
> set_current_state(TASK_RUNNING); and also
> current->state = TASK_RUNNING;
>
> Which one is most recent, and is there a s
On Sat, Sep 30, 2000 at 09:50:21PM -0400, Sandy Harris wrote:
> Don Becker has some text at:
>
> http://www.scyld.com/expert/irq-conflict.html
>
> which includes a section:
>
> > Why SA_INTERRUPT in the SCSI drivers is a Bad Thing
>
> > ... it could potentially have a very negative impact on a
On Mon, Oct 02, 2000 at 09:45:36PM +0200, Roman Zippel wrote:
> When that is done, please don't call __sti() directly and use some macro
> that can be overridden by the architectures.
What do you have in mind while making this suggestion? The irq highlevel layer
is pretty much architectural indip
On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote:
> We must be talking about different things. It of course detects it on
> ACK input, but only for data it did send itself. Every TCP detects
> reordering automatically on the input with the sequence number check,
> but all we still do is
On Wed, Sep 20, 2000 at 03:24:28PM +0200, Andi Kleen wrote:
> That would just break the whole idea behind softnet. When you're juggling
I agree ;(.
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 a
On Fri, 8 Sep 2000, David Woodhouse wrote:
>[EMAIL PROTECTED] said:
>> I guess Alexey point is that the current compiler doesn't notice
>> that.
>
>I don't understand why we're bringing empirical evidence into this
>discussion. Didn't we get into the horrible mess we've already got w.r.t.
I'm
On Mon, Sep 18, 2000 at 03:39:50PM -0700, Linus Torvalds wrote:
> Have you looked at the code it generates? Quite sad, really.
I read the asm produced by some of some of my testcases. The current spinlock
implementation seems to do exactly the _right_ thing in practice and nothing
more. "memory
On Mon, Sep 18, 2000 at 07:53:04PM -0400, John Wehle wrote:
> What version of gcc? Recently some work was done to improve the handling of
> constant memory.
I'm using 2.95.2 19991024.
Take this small testcase:
#include
int * p;
spinlock_t lock = SPIN_LOCK_UNLOCKED;
extern void dummy(int, in
On Tue, 29 Aug 2000, David S. Miller wrote:
> Date: Tue, 29 Aug 2000 04:26:18 +0200 (CEST)
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> Alpha definitely needs mb(), ld_l/st_c doesn't imply any memory
> barrier (yes, alpha is very aggressive in SMP 8).
&g
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Interestingly enough, the local variable case is one where "memory" does
>make a difference. Without "memory":
>
>movlp, %eax
>movl(%eax), %eax
>#APP
>#NO_APP
>
>With "memory":
>
>#APP
>#NO_APP
>movlp, %eax
>mov
On Thu, 7 Sep 2000, Franz Sirl wrote:
>In short terms:
>
>- __volatile__ assures that the code isn't reordered against other
>__volatile__ and isn't hoisted out of loops, nothing else
>- the "memory" clobber makes sure the asm isn't reordered against other
>memory accesses
Ok. That's all I wan
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>int *p;
>int func()
>{
> int x;
> x = *p;
> __asm__ __volatile__ ("" : : : "memory");
> x = *p;
> return x;
>}
>
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ > gcc -v
Reading specs from /usr/li
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Yes, it does.
Nice.
>.ident "GCC: (GNU) 2.96 2724 (experimental)"
>
>>From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
>.ident "GCC: (GNU) egcs
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
>
>Andrea Arcangeli wrote:
>> Maybe we can rely on the __volatile__ statement of the asm that will
>> enforce that i
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
>"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doe
On Tue, 29 Aug 2000, Andrea Arcangeli wrote:
>I'd prefer to have things like UnlockPage implemented as the architecture
>prefers (with a safe SMP common code default) instead of exporting zillons
I changed idea. I'd preferred to implement a mechanism that allows to
implement co
On Tue, Sep 19, 2000 at 04:01:26PM +0100, David Howells wrote:
> I can't remember exactly what it was now, but I think it was either something
> to do with spinlocks or bitops. I'll re-investigate tonight and see if I can
> come back with some benchmarks/code-snippets tomorrow.
Yes you should tel
On Mon, Sep 18, 2000 at 09:37:43PM -0400, John Wehle wrote:
> It's perhaps not optimal, however I'm not sure that it's wrong. In
It's not "wrong" in the sense that something breaks but it's definitely
suboptimal. There's no reason to reload a value that can't change because it's
embedded into th
On Thu, Sep 21, 2000 at 03:23:17PM -0700, David S. Miller wrote:
>
> How did you get away with adding a new member to task_struct yet not
> updating the INIT_TASK() macro appropriately? :-) Does it really
> compile?
As far as sleep_time is ok to be set to zero its missing initialization is
righ
On Tue, Sep 19, 2000 at 10:23:05AM -0700, Richard Henderson wrote:
> On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote:
> > Wrong: it's really loading the _address_.
> [...]
> > 80483f5: a1 a4 95 04 08
On Tue, Sep 19, 2000 at 07:22:48PM +0200, Jamie Lokier wrote:
> That instruction loads the _value_ of p. I.e. reads the memory from
> location 0x80495a4 into %eax. The source instruction was:
>
>movl p,%eax
>
> The instructions that you're thinking of, that load fixed addresses,
> look
On Tue, Sep 19, 2000 at 04:16:07PM -0400, John Wehle wrote:
> Umm ... "miscompilation"? As in the compiler produced the wrong code
> based on the input provided?
That's not a gcc bug (gcc is doing the right thing). It's the kernel that
should use the "memory" clobber in the spinlock implementati
On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> +static inline __u16 ___swab16(__u16 x)
> +{
> + return ((x & (__u16)0x00ffU) << 8) | ((x & (__u16)0xff00U) >> 8);
> +}
> +static inline __u32 ___swab16(__u32 x)
^
> +{
> + return ((x & (__u32
On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> Better would be to use statement blocks like
> #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
On Wed, Sep 20, 2000 at 01:58:32AM +0200, Martin Dalecki wrote:
> Not agreed. In this case older version of GCC will have
> almost exactly the same provlems as with functions.
I guess the object was to remove the mistake-prone side effects anyway...
Andrea
-
To unsubscribe from this list: send t
This patch fixes the spinlock problems in read_lock/write_lock and also some
alpha SMP race where clear_bit isn't enforcing a memory barrier, plus some
improvement in some place where we can check the waitqueue is not full before
entering wake_up. There's some minor alpha compile fix too.
On the
On Mon, Sep 25, 2000 at 11:51:39AM -0600, [EMAIL PROTECTED] wrote:
> It should probably be GFP_ATOMIC, if I understand the mm right.
poll_wait is called from the f_op->poll callback from select just before
a sleep and since it's allowed to sleep too it should be a GFP_KERNEL
(not ATOMIC). Using
On Fri, Sep 22, 2000 at 11:08:21AM -0700, Linus Torvalds wrote:
> The same is true in the filesystems - many of them want to change block or
> inode allocation bitmap bits, but they have to hold a lock anyway (usually
> the kernel lock in addition to the superblock lock.
The patch addresses the f
On Fri, Sep 22, 2000 at 10:35:16AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Sep 2000, Andrea Arcangeli wrote:
> >
> > This patch fixes the spinlock problems in read_lock/write_lock and also some
> > alpha SMP race where clear_bit isn't enforcing a memory
On Sun, Oct 08, 2000 at 08:27:24AM -0700, Linus Torvalds wrote:
> Why? Think NUMA. The global freepages number is NOT USABLE. Never will be.
> Because it's fundamentally a non-valid number to use - it has nothing to
> do with any reality, and never will.
>
> This is exactly my argument and beef w
On Mon, Oct 09, 2000 at 04:03:46PM +0100, Alan Cox wrote:
> > The situation persists, we have had two crashes on those servers today.
> >
> > The machines are usually very heavily loaded, 5-50.
> >
> > Please help.
> > Are there any patches to fix this behaviour ?
>
> You might want to try Andr
On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
Init can't be killed in 2.2.x latest, the same bugfix should be forward
ported to 2.4.x.
> Can you give me your rationale for selecting 'nice' processe
On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote:
> ignoring the kill would just preserve those bugs artificially.
If the oom killer kills a thing like init by mistake or init has a memleak
you'll notice both problems regardless of having a magic for init in a _very_
slow path so I don
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> No. It's only needed if your OOM algorithm is so crappy that
> it might end up killing init by mistake.
The algorithm you posted on the list in this thread will kill init if on 4Mbyte
machine without swap init is large 3 Mbytes and y
On Mon, Oct 09, 2000 at 12:30:20PM -0700, David Ford wrote:
> Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg
Init should never get killed. Killing init can be compared to destroy the TCP
stack. Some app can keep to run right for some minute until they run sock
On Mon, Oct 09, 2000 at 10:06:02PM +0200, Ingo Molnar wrote:
> i think the OOM algorithm should not kill processes that have
> process that has child processes likely results in unexpected behavior of
You just know what I think about those heuristics. I think all we need is a
per-task pagefault/a
On Mon, Oct 09, 2000 at 05:06:48PM -0300, Rik van Riel wrote:
> On Mon, 9 Oct 2000, Andrea Arcangeli wrote:
> > On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > > No. It's only needed if your OOM algorithm is so crappy that
> > > it migh
On Mon, Oct 09, 2000 at 09:38:08PM +0100, James Sutherland wrote:
> Shouldn't the runtime factor handle this, making sure the new process is
The runtime factor in the algorithm will make the first difference
only after lots lots of time (and the run_time can as well be wrong
because of jiffies wr
On Tue, Oct 10, 2000 at 04:38:02AM +0100, Philipp Rumpf wrote:
> Init should never die. If we get to do_exit in init we'll panic which is
> the right thing to do (reboot on critical systems).
If the page fault can fail with OOM on init, init will get a SIGSEGV while
running a signal handler (cop
On Tue, Oct 10, 2000 at 09:06:49AM +0200, Helge Hafting wrote:
> If you want init to live - prove that it don't eat too much memory.
I don't see why the machine should be stable only if init is small.
My kernel won't be stable only if init is small since it doesn't cost
anything to handle correct
On Wed, Oct 11, 2000 at 11:08:41AM +0200, Helge Hafting wrote:
> Nothing wrong with a big init - the problem is a memory-leaking init.
> That one will die anyway, wether it dies early from an OOM-killer
> or later when all other processes are gone don't really matter.
Indeed.
Andrea
-
To unsubsc
On Wed, Oct 11, 2000 at 03:35:40PM -0200, Marcelo Tosatti wrote:
> Now I'm not sure if this can be caused by a memory problem.
It can.
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
On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
> I honestly see nothing wrong with it. There are different parts of
> the compiler stressed by the kernel build as opposed to most userland
> compilation, and furthermore the desired compiler stability/feature
> ratio is different
On Fri, Oct 13, 2000 at 02:09:42AM +0200, Sasi Peter wrote:
> Hi!
>
> Unfortunatelly I couldn't apply it:
> [root@iq src]# bzcat VM-global-2.2.18pre9-6.bz2 |patch -p0
Please check with `head -4 VM/Makefile` that it's 2.2.18pre15.
andrea@athlon:~/devel/kernel > fork 2.2.18pre15 z; cd z; apply
~
On Thu, Oct 12, 2000 at 04:48:55PM -0700, [EMAIL PROTECTED] wrote:
>
> if you aren't comfortable with dropping a lot of the 2.2.18preX stuff onto
> a production box, there is also the 2.2.18pre2aa2 kernel that andrea made
2.2.18pre2aa2 should be kind of rock solid (the only problem it has
as eve
On Thu, Oct 12, 2000 at 12:47:39AM +0200, Krzysztof Sierota wrote:
> Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches
> applied and some other stuff that we needed, and the machines are stable
I recommend using 2.2.18pre15aa1 (without using nfsv3 in production f
On Fri, Oct 13, 2000 at 04:23:51PM +0200, David Weinehall wrote:
> On Fri, Oct 13, 2000 at 04:14:32PM +0200, Andrea Arcangeli wrote:
> > On Thu, Oct 12, 2000 at 12:47:39AM +0200, Krzysztof Sierota wrote:
> > > Marcelo Tosati assembled a kernel for us that had Andrea Arcan
On Fri, Oct 13, 2000 at 10:54:50AM -0400, Jeff Garzik wrote:
> Andrea Arcangeli wrote:
> >
> > On Thu, Oct 12, 2000 at 12:47:39AM +0200, Krzysztof Sierota wrote:
> > > Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches
> > > applied an
On Fri, Oct 13, 2000 at 11:20:14AM -0400, Jeff Garzik wrote:
> No problem here, I always use 8192 r/w size :)
You would help me if you could try to do the same with 2.2.18pre15aa1 on both
client and server side nfsv3 using also files larger than 2G. Maybe the
problem with the bigger r/w size isn
On Fri, Oct 13, 2000 at 05:26:25PM +0200, Andrea Arcangeli wrote:
> You would help me if you could try to do the same with 2.2.18pre15aa1 on both
Jeff, don't waste time trying it because Jay Weber just fixed the bug.
Andrea
-
To unsubscribe from this list: send the line "unsu
On Sat, Oct 14, 2000 at 07:17:57PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 14 Oct 2000, Rogier Wolff wrote:
> > > Note that it is usually MUCH better to do this the other way around:
> > > having a kernel-side buffer, and mapping that into user space. I don't
> > > understand why so many peop
On Sun, Oct 15, 2000 at 03:48:55PM -0400, Jeff Garzik wrote:
> Changes:
> * both: we know we are in an interrupt, so
> s/spin_lock_irqsave/spin_lock/
There request_irq is not called passing the SA_INTERRUPT flag so the irq
handler is recalled with irqs enabled and in turn irqsave is necessary.
A
On Mon, Oct 16, 2000 at 11:22:09AM +0930, Paul Schulz wrote:
>
> I'm seeing a similar problem with the Xircom Realport card
> which uses the 'xircom_tulip_cb' driver.
>
> Workaround:
>
> Putting the card into promiscuous mode seems to get it going again.
The fix is been finally merged in pcmc
On Mon, Oct 16, 2000 at 11:29:27AM -0700, Linus Torvalds wrote:
> The page count is (or should be) sufficient, and if it weren't sufficient
> that would be a bug in the swap-out handling of anonymous or shm memory. I
If the page isn't locked swap_out will unmap it from the pte and anybody will
be
On Mon, Oct 16, 2000 at 10:14:01PM +0100, Stephen C. Tweedie wrote:
> [..] If the VM
> chooses to unmap the page temporarily, then as long as the page
> remains in physical memory, then a subsequent page fault will
> reestablish the mapping. [..]
Correct. But the problem is that the page won't st
On Mon, Oct 16, 2000 at 02:59:59PM -0700, Linus Torvalds wrote:
> No. Because "pinning" is _stupid_.
Pinning using map_user_kiobuf looks just the other way around of what we do
usually with the mmap callback of the device driver and remap_page_range. I
considered "pinning" just to convert the us
On Mon, Oct 16, 2000 at 03:21:11PM -0700, Linus Torvalds wrote:
> Pinning will not happen.
Pinning happens every day on my box while I use rawio.
If you want to avoid pinning _userspace_ pages then we should delete
map_user_kiobuf and define a new functionality and API to replace RAWIO for
DBMS
On Mon, Oct 16, 2000 at 05:31:47PM -0400, Jeff Garzik wrote:
> Andrea Arcangeli wrote:
> >
> > On Sun, Oct 15, 2000 at 03:48:55PM -0400, Jeff Garzik wrote:
> > > Changes:
> > > * both: we know we are in an interrupt, so
> > > s/spin_lock_irqsave/sp
On Mon, Oct 16, 2000 at 09:31:42PM -0400, Jeff Garzik wrote:
> I understand SA_INTERRUPT, my question in the previous e-mail was more
> basic: keyboard_interrupt calls handle_kbd_event with local interrupts
> disabled. [..]
Woops sorry, I misunderstood your question.
>[..] Why are local interru
On Tue, Oct 17, 2000 at 05:43:34PM +0200, Jes Sorensen wrote:
> Which shouldn't matter as the irq source should be disabled. In fact I
> thought we were guaranteed not to be re-interrupted in a handler
> unless one explicitly does __sti(), has this changed?
A single irq handler won't be re-interr
On Tue, Oct 17, 2000 at 05:26:23AM -0400, Jeff Garzik wrote:
> Well, the -spin lock- exists for serialization. My question is Why
> does pc_keyb irq handler disable local irqs for this case? What is the
> race/deadlock that exists with spin_lock in the irq handler, but does
> not exist with
On Mon, Oct 16, 2000 at 08:11:55PM -0700, Linus Torvalds wrote:
> Oh. So to fix a bug, you say "either delete the code, or do something else
> that is completely idiotic instead"?
I'm not saying this because the "something else" doesn't look completly idiotic
to me.
> Andrea, explain to me how p
On Tue, Oct 17, 2000 at 11:36:22AM -0700, Linus Torvalds wrote:
> On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
> >
> > > Andrea, explain to me how pinning _could_ work? Explain to me how you'd
> > > lock down pages in virtual address space with multiple threads
On Tue, Oct 17, 2000 at 12:27:30PM -0700, David S. Miller wrote:
> Hint: smp_flush_tlb_page()
>
> Current kiobufs never need to do that, under any circumstances.
> This is not by accident.
I don't understand. flush_tlb_page() done in the context of a thread won't care
about the state of the phys
On Tue, Oct 17, 2000 at 02:04:10PM -0700, Linus Torvalds wrote:
> It so happens that the vmscan stuff won't ever remove a physical page
> mapping, but that's simply because such a page CANNOT be swapped out. How
So if I write a mechanism that allows those driver-private-pages that are used
for DM
On Tue, Oct 17, 2000 at 07:21:04PM -0400, Jeff Garzik wrote:
> I wonder if q40_keyb has the same thing to worry about
It seems no, it looks like we can remove the irqsave from there.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Oct 17, 2000 at 01:02:01PM -0700, Linus Torvalds wrote:
> But what about things like:
> - linearized circular buffers (where "linearized" means that the buffer
>is mapped twice or more consecutively virtually in memory, so that the
>user doesn't need to worry about the boundary co
On Tue, Oct 17, 2000 at 09:26:07PM -0700, Linus Torvalds wrote:
> Maybe you mean PG_reserved?
Yes of course. (sorry for the typo)
> Quite frankly, the way I'd conceptually prefer people do these kinds of
> DMA buffers etc is to just have a "nopage()" function, and let that
> nopage() function j
On Tue, Oct 17, 2000 at 09:42:36PM -0700, Linus Torvalds wrote:
> - get PTE entry, clear it out.
> - if PTE was dirty, add the page to the swap cache, and mark it dirty,
>but DON'T ACTUALLY START THE IO!
> - free the page.
>
> Basically, we removed the page from the virtual mapping, and it
701 - 800 of 2012 matches
Mail list logo
