Roel Bindels wrote:
> Hello listers,
>
> I'm tutor on the Faculty ICT, department NID. This is a bachelor degree
> and we are preparing our students to become something more then just
> System Administrators (such as manager, consulting, etc). Since this
> department is part of the Microsoft ca
> > AS_CMTIME is only for the case, when the "file modified since the last
> > msync" info is lost from the ptes, e.g. because of page reclaim.
> >
> > So it doesn't matter if AS_CMTIME is not set, is_page_modified() will
> > provide the necessary barrier.
>
> The trouble is, we went from a pull
On Tue, 2007-03-06 at 23:18 +0100, Miklos Szeredi wrote:
> > > None what so ever, but I always think of msync as a rare function
> > > (infrequent when compared to (minor) faults overall). But I don't have
> > > numbers backing that up either.
> > >
> > > Also, the radix tree scan you do isn't exa
On Tue, 06 Mar 2007 19:04:44 +0100
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Fix race in clear_page_dirty_for_io() as suggested by Linus.
please describe this race.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majo
> > None what so ever, but I always think of msync as a rare function
> > (infrequent when compared to (minor) faults overall). But I don't have
> > numbers backing that up either.
> >
> > Also, the radix tree scan you do isn't exactly cheap either.
> >
> > So what I was wondering is whether its
On Tue, 2007-03-06 at 22:47 +0100, Peter Zijlstra wrote:
> On Tue, 2007-03-06 at 22:24 +0100, Miklos Szeredi wrote:
> > > I'm not liking this, its not a constant operation as the name implies.
> >
> > OK, I'll think of something better.
> >
> > > And it style is a bit out of line with the rest of
> > > I can understand you wanting to avoid the overhead of the minor faults
> > > resulting from using page_mkclean(), but I'm not sure its worth it.
> >
> > It would be nice if the cost of MS_ASYNC wouldn't be too high. And I
> > do have the feeling that minor faults are far more expensive than
On Tue, 2007-03-06 at 22:24 +0100, Miklos Szeredi wrote:
> > I'm not liking this, its not a constant operation as the name implies.
>
> OK, I'll think of something better.
>
> > And it style is a bit out of line with the rest of rmap.
> >
> > The thing it actually does is page_mkclean(), all it
> I'm not liking this, its not a constant operation as the name implies.
OK, I'll think of something better.
> And it style is a bit out of line with the rest of rmap.
>
> The thing it actually does is page_mkclean(), all it doesn't do is
> setting the pte read-only.
>
> I can understand you wa
On Tue, 2007-03-06 at 19:04 +0100, Miklos Szeredi wrote:
> plain text document attachment (mmap_mtime.patch)
> Index: linux/mm/rmap.c
> ===
> --- linux.orig/mm/rmap.c 2007-03-06 15:17:46.0 +0100
> +++ linux/mm/rmap.c 20
On Tue, Mar 06, 2007 at 06:43:34PM +0100, Roel Bindels wrote:
> Ok, but don't you guys have some fact I can build a case with?? I don't
> think that my college's will take me serious if I come with this store,
> even it is true ;)
You are crossposting far too widely to some wildly inappropriate li
Jan Kara wrote:
> On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
>> Christoph Hellwig wrote:
>>> fallocate with the whence argument and flags is already quite complicated,
>>> I'd rather have another call for placement decisions, that would
>>> be called on an fd to do placement decissions for any
From: Miklos Szeredi <[EMAIL PROTECTED]>
The function do_lo_send_aops() should call
balance_dirty_pages_ratelimited() after each page similarly to
generic_file_buffered_write().
Without this, writing the loop device directly (not through a
filesystem) is very slow, and also slows the whole system
From: Andrew Morton <[EMAIL PROTECTED]>
[EMAIL PROTECTED]: bugfix]
Miklos Szeredi <[EMAIL PROTECTED]>:
Changes:
- updated to apply after clear_page_dirty_for_io() race fix
This is needed for
- balance_dirty_pages() deadlock fix
- fuse dirty page accounting
I have no idea how serious the sc
From: Miklos Szeredi <[EMAIL PROTECTED]>
Changes:
v2:
o set AS_CMTIME flag in clear_page_dirty_for_io() too
o don't clear AS_CMTIME in file_update_time()
o check the dirty bit in the page tables
v1:
o moved check from __fput() to remove_vma(), which is more logical
o changed set_page_dirty()
From: Miklos Szeredi <[EMAIL PROTECTED]>
Fix NULL pointer dereference in __mpage_writepage. This probably
doesn't matter in practice, but this is the original behavior.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/mpage.c
From: Miklos Szeredi <[EMAIL PROTECTED]>
Fix race in clear_page_dirty_for_io() as suggested by Linus.
Split the page dirtying into two phases:
1) done for each dirtying attempt
2) done only when the page's dirty flag changed from clean to dirty
For 1 a_ops->set_page_dirty() is used (couldn'
From: Miklos Szeredi <[EMAIL PROTECTED]>
This deadlock happens, when dirty pages from one filesystem are
written back through another filesystem. It easiest to demonstrate
with fuse although it could affect looback mounts as well (see
following patches).
Let's call the filesystems A(bove) and B(
From: Miklos Szeredi <[EMAIL PROTECTED]>
This deadlock is similar to the one in balance_dirty_pages, but
instead of waiting in balance_dirty_pages after submitting a write
request, it happens during a memory allocation for filesystem B before
submitting a write request.
It is easy to reproduce on
From: Miklos Szeredi <[EMAIL PROTECTED]>
There's a slight problem with filesystem type representation in fuse
based filesystems.
>From the kernel's view, there are just two filesystem types: fuse and
fuseblk. From the user's view there are lots of different filesystem
types. The user is not eve
There's a new patch, which fixes the race in clear_page_dirty_for_io()
and cleans up the page dirtying logic. And the mmap mtime/ctime
update patch has seen much improvement. The others are resends and
fixes.
I'm not resending the fuse writable mmap patches until the fate of the
deadlock fixes i
Vu Pham schreef:
> On Tue, 2007-03-06 at 09:14 -0800, Bill Campbell wrote:
> [...]
>> One of the major differences between folks competent in Linux and Unix and
>> Windows ``experts'' is that the *nix people usually start by trying to
>> analyse and fix problems while MCSEs only know the Three R's
On Mon, Mar 05, 2007, Roel Bindels wrote:
>Hello listers,
>
>I'm tutor on the Faculty ICT, department NID. This is a bachelor degree
>and we are preparing our students to become something more then just
>System Administrators (such as manager, consulting, etc). Since this
>department is part of
On Tue, 2007-03-06 at 09:14 -0800, Bill Campbell wrote:
[...]
> One of the major differences between folks competent in Linux and Unix and
> Windows ``experts'' is that the *nix people usually start by trying to
> analyse and fix problems while MCSEs only know the Three R's of Windows,
> Reboot, Re
Ulrich Drepper wrote:
> Christoph Hellwig wrote:
>> fallocate with the whence argument and flags is already quite complicated,
>> I'd rather have another call for placement decisions, that would
>> be called on an fd to do placement decissions for any further allocations
>> (prealloc, write, etc)
>
On Tue, Mar 06, 2007 at 06:36:09AM -0800, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> > fallocate with the whence argument and flags is already quite complicated,
> > I'd rather have another call for placement decisions, that would
> > be called on an fd to do placement decissions for any fu
On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> > fallocate with the whence argument and flags is already quite complicated,
> > I'd rather have another call for placement decisions, that would
> > be called on an fd to do placement decissions for any further allocation
Christoph Hellwig wrote:
> fallocate with the whence argument and flags is already quite complicated,
> I'd rather have another call for placement decisions, that would
> be called on an fd to do placement decissions for any further allocations
> (prealloc, write, etc)
Yes, posix_fallocate shouldn
28 matches
Mail list logo
