On Tue, 24 Oct 2000, Pavel Machek wrote:
> Hi!
>
> > > [EMAIL PROTECTED] said:
> > > > You can also pretty trivially keep track of an error term so that the
> > > > clock is right on average:
> > >
> > > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > >
Hi!
> > [EMAIL PROTECTED] said:
> > > You can also pretty trivially keep track of an error term so that the
> > > clock is right on average:
> >
> > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > Shifting the timer tick onto the RTC will give me that.
> >
>
On Tue, 24 Oct 2000, Petr Vandrovec wrote:
> On 23 Oct 00 at 23:05, Alexander Viro wrote:
>
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
> > Unfortunately, clean test would take the
On 23 Oct 00 at 23:05, Alexander Viro wrote:
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
> Unfortunately, clean test would take the backport of ext2 changes
> (truncate-related, happened around
On 23 Oct 00 at 23:05, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the
On Tue, 24 Oct 2000, Petr Vandrovec wrote:
On 23 Oct 00 at 23:05, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of
Hi!
[EMAIL PROTECTED] said:
You can also pretty trivially keep track of an error term so that the
clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that.
Even if we _do_
On Tue, 24 Oct 2000, Pavel Machek wrote:
Hi!
[EMAIL PROTECTED] said:
You can also pretty trivially keep track of an error term so that the
clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Note that if there really are only 9 "nopage" routines, then it is a lot
> easier to just add the single "SetPageUptodate(page)" into those 9
> routines, and thus let the VM know of the race.
Works for me. And yes, the list of ->nopage instances
On Tue, 24 Oct 2000, Alexander Viro wrote:
>
> It's not the only problem, but I would feel _much_ safer if pagefault
> wouldn't rely on pagecache miss. Actually... Hey. Why don't we do the
> insertion into page tables _within_ ->nopage()?
NO!
We used to do this a LOONG time ago.
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
>
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
>
> I don't think that is it - that code
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very straightforward (and is
needed on some silly
Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Also, the fact that Petr didn't see anything trigger in nopage() makes me
> nervous again. Even if the problem happened during read-ahead, it should
> have gotten into the address space only through nopage. Maybe there is
> some vma that isn't added
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> I'm starting to suspect that we leave this path as-is, and just fix the
> mapping case (and PageUptodate() can work there). That should also avoid
> the nasties.
..and even that looks like I'd have to do the quick-and-dirty case with
the race
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /
Actually, it turns out that even with this issue fixed, there's the more
serious issue that the page _has_ to be removed from the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /.
Yeah, the way the truncate logic works right now truncate_whole_page() has
to remove the page from the inode list - otherwise
On 23 Oct 00 at 14:34, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> > >
> > > Nope, that just makes the race window smaller. We should check for i_size
> > > after we've gotten the page table lock and just before actually
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > Nope, that just makes the race window smaller. We should check for i_size
> > after we've gotten the page table lock and just before actually entering
> > the page into the page tables. Otherwise
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. With sleep(60) no oops occur (it takes ~45 secs to exit child).
> This signals to me: should not vmtruncate_list acquire mm->mmap_sem,
> if it modifies page tables?
No.
It should get the page_table lock, but that is sufficient for
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> > obvious ones:
> > * filemap_nopage() needs the second check for ->i_size. Upon exit.
>
> Nope, that just makes
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> obvious ones:
> * filemap_nopage() needs the second check for ->i_size. Upon exit.
Nope, that just makes the race window smaller. We should check for i_size
On 23 Oct 00 at 13:57, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> > First page->mapping == NULL entry in syslog is dated 22:23:58, but
> > couple of entries was lost before (probably I should print only '.' for
> > each such page; this run there was more than 100 such
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > > the race open, and make truncate_complete_page() just leave such a
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. Bad news. No problem was catched in filemap_nopage, but one
> (of 57000) pages was dirty and had page->mapping == NULL... (maybe
> only one was caused that this was just after bootup, with plenty of memory)
> Maybe I should look at readahead
On Mon, 23 Oct 2000, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race,
On 23 Oct 00 at 16:13, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race,
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Al, any ideas? I have this feeling that the simplest fix is just to leave
> the race open, and make truncate_complete_page() just leave such a "racy"
> page in the page cache. It will still race, and the invalid page will
> still exist, but the end
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> > I'll take a better look at the truncate case (I consider the invalidate
> > case closed). Do you have a simple test-program around?
>
> Well, I cannot say simple. As I was not able to reproduce it with only
> one task, code below:
Ok, without
On 23 Oct 00 at 12:09, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> >
> > Hi Linus,
> > unfortunately, this does not explain problem I reported. In my case,
> > underlying fs is ext2, and there is no locking around - only one task
> > does ftruncate() on (big) shareable
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Hi Linus,
> unfortunately, this does not explain problem I reported. In my case,
> underlying fs is ext2, and there is no locking around - only one task
> does ftruncate() on (big) shareable mapped file (original code does it to
> prevent dirty
On 23 Oct 00 at 10:33, Linus Torvalds wrote:
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> >As for simply settling for a self-consistent mmap() rather than
> >tackling the problem of rereading; the main crime is that you're
> >rendering file locking unusable.
...
> This is not a crime.
>
In article <[EMAIL PROTECTED]>,
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
>As for simply settling for a self-consistent mmap() rather than
>tackling the problem of rereading; the main crime is that you're
>rendering file locking unusable.
This is not a crime.
Anybody who uses file locking
On Mon, 23 Oct 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > You can also pretty trivially keep track of an error term so that the
> > clock is right on average:
>
> True, but I don't want 'right on average'. I want 'not screwed with at all'.
> Shifting the timer tick onto the
[EMAIL PROTECTED] said:
> You can also pretty trivially keep track of an error term so that the
> clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that.
Even if we _do_ get the maths
On Mon, 23 Oct 2000, David Woodhouse wrote:
> See arch/i386/kernel/time.c:
>
> /* This function must be called with interrupts disabled
> * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
> *
> * However, the pc-audio speaker driver changes the divisor so that
> * it
[EMAIL PROTECTED] said:
> Apparently Linus doesn't like the way it handles interrupts or
> something, and is therefore 'wrong.' ::shrug:: As long as it's
> available though, I'll use it ;p
It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to
shift the system timer onto the
[EMAIL PROTECTED] said:
Apparently Linus doesn't like the way it handles interrupts or
something, and is therefore 'wrong.' ::shrug:: As long as it's
available though, I'll use it ;p
It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to
shift the system timer onto the RTC,
On Mon, 23 Oct 2000, David Woodhouse wrote:
See arch/i386/kernel/time.c:
/* This function must be called with interrupts disabled
* It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
*
* However, the pc-audio speaker driver changes the divisor so that
* it gets
[EMAIL PROTECTED] said:
You can also pretty trivially keep track of an error term so that the
clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that.
Even if we _do_ get the maths
On Mon, 23 Oct 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
You can also pretty trivially keep track of an error term so that the
clock is right on average:
True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will
In article [EMAIL PROTECTED],
Trond Myklebust [EMAIL PROTECTED] wrote:
As for simply settling for a self-consistent mmap() rather than
tackling the problem of rereading; the main crime is that you're
rendering file locking unusable.
This is not a crime.
Anybody who uses file locking over NFS
On 23 Oct 00 at 10:33, Linus Torvalds wrote:
Trond Myklebust [EMAIL PROTECTED] wrote:
As for simply settling for a self-consistent mmap() rather than
tackling the problem of rereading; the main crime is that you're
rendering file locking unusable.
...
This is not a crime.
...
And yes,
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Hi Linus,
unfortunately, this does not explain problem I reported. In my case,
underlying fs is ext2, and there is no locking around - only one task
does ftruncate() on (big) shareable mapped file (original code does it to
prevent dirty pages
On 23 Oct 00 at 12:09, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Hi Linus,
unfortunately, this does not explain problem I reported. In my case,
underlying fs is ext2, and there is no locking around - only one task
does ftruncate() on (big) shareable mapped
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
I'll take a better look at the truncate case (I consider the invalidate
case closed). Do you have a simple test-program around?
Well, I cannot say simple. As I was not able to reproduce it with only
one task, code below:
Ok, without running
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the invalid page will
still exist, but the end result
On 23 Oct 00 at 16:13, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Yes. Bad news. No problem was catched in filemap_nopage, but one
(of 57000) pages was dirty and had page-mapping == NULL... (maybe
only one was caused that this was just after bootup, with plenty of memory)
Maybe I should look at readahead code?
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
On 23 Oct 00 at 13:57, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
First page-mapping == NULL entry in syslog is dated 22:23:58, but
couple of entries was lost before (probably I should print only '.' for
each such page; this run there was more than 100 such pages)
On Mon, 23 Oct 2000, Alexander Viro wrote:
That's fine, but I'm afraid that we'll need a bit more than that. A couple of
obvious ones:
* filemap_nopage() needs the second check for -i_size. Upon exit.
Nope, that just makes the race window smaller. We should check for i_size
after
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
That's fine, but I'm afraid that we'll need a bit more than that. A couple of
obvious ones:
* filemap_nopage() needs the second check for -i_size. Upon exit.
Nope, that just makes the race
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Yes. With sleep(60) no oops occur (it takes ~45 secs to exit child).
This signals to me: should not vmtruncate_list acquire mm-mmap_sem,
if it modifies page tables?
No.
It should get the page_table lock, but that is sufficient for anybody who
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Nope, that just makes the race window smaller. We should check for i_size
after we've gotten the page table lock and just before actually entering
the page into the page tables. Otherwise we'll
On 23 Oct 00 at 14:34, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Nope, that just makes the race window smaller. We should check for i_size
after we've gotten the page table lock and just before actually entering
the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
With ClearPageDirty() kernel locked up (but no watchdog, so probably
some livelock) during bootup after fsck /.
Yeah, the way the truncate logic works right now truncate_whole_page() has
to remove the page from the inode list - otherwise truncate
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
With ClearPageDirty() kernel locked up (but no watchdog, so probably
some livelock) during bootup after fsck /
Actually, it turns out that even with this issue fixed, there's the more
serious issue that the page _has_ to be removed from the page
On Mon, 23 Oct 2000, Linus Torvalds wrote:
I'm starting to suspect that we leave this path as-is, and just fix the
mapping case (and PageUptodate() can work there). That should also avoid
the nasties.
..and even that looks like I'd have to do the quick-and-dirty case with
the race still
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Also, the fact that Petr didn't see anything trigger in nopage() makes me
nervous again. Even if the problem happened during read-ahead, it should
have gotten into the address space only through nopage. Maybe there is
some vma that isn't added to
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively
On Mon, 23 Oct 2000, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very straightforward (and is
needed on some silly architectures
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very
On Tue, 24 Oct 2000, Alexander Viro wrote:
It's not the only problem, but I would feel _much_ safer if pagefault
wouldn't rely on pagecache miss. Actually... Hey. Why don't we do the
insertion into page tables _within_ -nopage()?
NO!
We used to do this a LOONG time ago.
Distributing the
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Note that if there really are only 9 "nopage" routines, then it is a lot
easier to just add the single "SetPageUptodate(page)" into those 9
routines, and thus let the VM know of the race.
Works for me. And yes, the list of -nopage instances that
ROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3
>
>> Is there a major compelling reason that this patch isn't included
>> in the standard kernel tree?
>>
>>
>> --
> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
>
>
> --
> Mike A. Harris - Linux advocate - Open source advocate
> Computer Consultant - Capslock
Is there a major compelling reason that this patch isn't included
in the standard kernel tree?
--
Mike A. Harris - Linux advocate - Open source advocate
Computer Consultant - Capslock Consulting
-ASCII
Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3
Is there a major compelling reason that this patch isn't included
in the standard kernel tree?
--
Mike A. Harris - Linux advocate - Open source
Greetings all:
I was doing some benchmark between kernels and i came out with
this results, for what I can see, 2.2.17 with the ide_patch is faster,
although it uses more CPU, but then again i could be wrong, any ideas?
-Rodrigo
2.4.0-test10-pre3 FS=ext2 AMD v1.2 (viper
On 16 Oct 2000, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:[EMAIL PROTECTED]
> In newsgroup: linux.dev.kernel
> >
> > > but intel refuse to guarantee they wont produce an actual '786' class
> > > CPU.
> >
> > Worry about that if/when it happens ?
>
> Dare one
Hi,
Something weird is going on with VFS return codes with kernel
2.4.0-test10-pre3:
[root@sturm glibc-2.1.92]# df /var/tmp
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 127383127383 0 100% /var
[root@sturm glibc-2.1.92]# df -i /var/tmp
On 16 Oct 2000, H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
but intel refuse to guarantee they wont produce an actual '786' class
CPU.
Worry about that if/when it happens ?
Dare one guess the 786 is
Greetings all:
I was doing some benchmark between kernels and i came out with
this results, for what I can see, 2.2.17 with the ide_patch is faster,
although it uses more CPU, but then again i could be wrong, any ideas?
-Rodrigo
2.4.0-test10-pre3 FS=ext2 AMD v1.2 (viper
On Thu, 19 Oct 2000, Linus Torvalds wrote:
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty one */
Wait a second.
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> Again, consider the case when two processes share the
> mapping. Process A has page faulted in. Page is
> invalidated. Process B tries to access the same page. If you
> leave it in page tables of A you _MUST_ leave it
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> For the general case of the page cache I think we can keep them quite
> simple:
>
> + We do in any case want to drop all pages that are unreferenced. (The
> reason for flushing may be that the file size has changed.)
>
> + For pages that are
On 20 Oct 2000, Trond Myklebust wrote:
> > " " == Russell King <[EMAIL PROTECTED]> writes:
>
> > invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> > do_fcntl sys_fcntl
>
> > So I guess that NFS locking is really bad if the region is
> > mmapped!
>
> Yep,
On 20 Oct 2000, Trond Myklebust wrote:
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
OK, so what should happen if user does mmap() on NFS file, dirties
On Fri, 20 Oct 2000, Roger Larsson wrote:
> Is it legal/good practice to unmap the file after closing it?
Yes.
> (Since the sharing needs the fd to mmap it)
It doesn't. Mapping needs struct file * and it doesn't care about
fd. mmap() takes a reference to struct file by fd you've passed and
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> > " " == David S Miller <[EMAIL PROTECTED]> writes:
>
> > Actually, judging by the trace you provided Russell, I'd say
> > this is some peculiarity with NFS silly rename handling, and
> > it'd be best to look for the bug in that
[ Final comment, and then I'll shut up ]
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> I'm saying that we're much much better off guaranteeing local consistency
> over knowingly breaking local consistency over a uncertain global
> consistency issue. Especially as NFS has never guaranteed global
> consistency in the first place, and
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> which is really really bad, because now you have the case that
> you have 'n' copies of the same page in memory, with 'n' users,
> out of which 'n-1' users have the wrong page. And those 'n-1'
> users don't even have
On 20 Oct 2000, Trond Myklebust wrote:
>
> The problem here is that NFS pages have 3 rather than 2 states:
> 1) mmapped & correct.
> 2) mmapped & incorrect. (but possibly dirty)
> 3) Unmapped
>
> For case 1), we clearly want to have the page in inode->i_mapping.
> For cases 2) & 3) we
On 20 Oct 2000, Trond Myklebust wrote:
>
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
> The existence of file locks that aren't page aligned, as well as
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> The advantage of clearing the uptodate flag (as opposed to
> doing what we do now - dropping the page altogether) is that
> there would be no cache aliasing issues, and there would be no
> issues with a page and its
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, that "invalidate_inode_pages()" thing is just wrong - we
> can't just remove pages that are mapped etc, because that would
> result in no end of fun aliasing problems etc.
> How about adding a test in
Alexander Viro writes:
> Trond, I'm not asking about implementation - the question being what
> semantics do you want for nfs_zap_caches() wrt user-mapped pages.
Ok, looking through sendmail, and then db2, the situation is
created by the db2 library. If the process does the following:
1.
On 19 Oct 00 at 16:32, Linus Torvalds wrote:
> How about adding a test in invalidate_inode_pages() like
>
> /* We cannot invalidate a locked page */
> if (TryLockPage(page))
> continue;
>
> + /* We cannot invalidate a page that is in use */
> + if
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> So what exactly do you want it to do when page is mapped by
> user process? Should it remain visible or not? What should
> happen if process writes to that page?
> Trond, I'm not asking about implementation - the
On Fri, 20 Oct 2000, Trond Myklebust wrote:
>
> The problem lies with writes that haven't yet been msync()ed (and
> hence do not have writebacks). For shared mappings, one should perhaps
> schedule an automatic msync() of the dirty pages (???). For private
> mappings, perhaps the best thing
On Fri, 20 Oct 2000, Trond Myklebust wrote:
The problem lies with writes that haven't yet been msync()ed (and
hence do not have writebacks). For shared mappings, one should perhaps
schedule an automatic msync() of the dirty pages (???). For private
mappings, perhaps the best thing would
" " == Alexander Viro [EMAIL PROTECTED] writes:
So what exactly do you want it to do when page is mapped by
user process? Should it remain visible or not? What should
happen if process writes to that page?
Trond, I'm not asking about implementation - the question being
On 19 Oct 00 at 16:32, Linus Torvalds wrote:
How about adding a test in invalidate_inode_pages() like
/* We cannot invalidate a locked page */
if (TryLockPage(page))
continue;
+ /* We cannot invalidate a page that is in use */
+ if
Alexander Viro writes:
Trond, I'm not asking about implementation - the question being what
semantics do you want for nfs_zap_caches() wrt user-mapped pages.
Ok, looking through sendmail, and then db2, the situation is
created by the db2 library. If the process does the following:
1. creates
" " == Linus Torvalds [EMAIL PROTECTED] writes:
Btw, that "invalidate_inode_pages()" thing is just wrong - we
can't just remove pages that are mapped etc, because that would
result in no end of fun aliasing problems etc.
snip
How about adding a test in
On 20 Oct 2000, Trond Myklebust wrote:
Under NFS the problem is that pages can (and *should*) be invalidated
despite there being pending write backs. The server can trigger the
need for a cache invalidation at any time.
The existence of file locks that aren't page aligned, as well as
On 20 Oct 2000, Trond Myklebust wrote:
The problem here is that NFS pages have 3 rather than 2 states:
1) mmapped correct.
2) mmapped incorrect. (but possibly dirty)
3) Unmapped
For case 1), we clearly want to have the page in inode-i_mapping.
For cases 2) 3) we don't.
I
1 - 100 of 211 matches
Mail list logo
