Hugh Dickins wrote:
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a
On Thu, 10 May 2007, Nick Piggin wrote:
> >
> > The filesystem (or page cache) allows pages beyond i_size to come
> > in there? That wasn't a problem before, was it? But now it is?
>
> The filesystem still doesn't, but if i_size is updated after the page
> is returned, we can have a problem
Hugh Dickins wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second
On Wed, 9 May 2007, Nick Piggin wrote:
> Hugh Dickins wrote:
> > On Wed, 2 May 2007, Nick Piggin wrote:
>
> > > >But I'm pretty sure (to use your words!) regular truncate was not racy
> > > >before: I believe Andrea's sequence count was handling that case fine,
> > > >without a second
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
OK, I think you're right. I _think_ it should also
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
OK, I think you're right. I _think_ it should also
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
Hugh Dickins wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a problem that was
Hugh Dickins wrote:
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a
On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
> These ops could also be put to use in bit spinlocks, buffer lock, and
> probably a few other places too.
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little
On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
These ops could also be put to use in bit spinlocks, buffer lock, and
probably a few other places too.
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little
Nick Piggin wrote:
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
Nick Piggin wrote:
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that
Andrew Morton wrote:
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
-
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> void fastcall unlock_page(struct page *page)
> {
> + VM_BUG_ON(!PageLocked(page));
> smp_mb__before_clear_bit();
> - if (!TestClearPageLocked(page))
> - BUG();
> -
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
{
DEFINE_WAIT_BIT(wait, >flags, PG_locked);
+ set_bit(PG_waiters, >flags);
+ if (unlikely(!TestSetPageLocked(page))) {
What happens if another cpu is coming
On Thu, 3 May 2007, Nick Piggin wrote:
> >>@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
> > > {
> > > DEFINE_WAIT_BIT(wait, >flags, PG_locked);
> > >
> > >+ set_bit(PG_waiters, >flags);
> > >+ if (unlikely(!TestSetPageLocked(page))) {
> >
> > What happens if another cpu is coming
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
G5
pagefault fork exec
2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
+patch 1.71-1.73
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
The problem is that lock/unlock_page is expensive on powerpc, and
if we improve that, we improve more than just the fault handler...
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
On Thu, 3 May 2007, Nick Piggin wrote:
>
> The problem is that lock/unlock_page is expensive on powerpc, and
> if we improve that, we improve more than just the fault handler...
>
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
There's a strong
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
>
> G5
> pagefault fork exec
> 2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
> +patch 1.71-1.73 175.2-180.8
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
G5
pagefault fork exec
2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
+patch 1.71-1.73 175.2-180.8 780.5-794.2
On Thu, 3 May 2007, Nick Piggin wrote:
The problem is that lock/unlock_page is expensive on powerpc, and
if we improve that, we improve more than just the fault handler...
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
There's a strong whiff of
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
The problem is that lock/unlock_page is expensive on powerpc, and
if we improve that, we improve more than just the fault handler...
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
G5
pagefault fork exec
2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
+patch 1.71-1.73
On Thu, 3 May 2007, Nick Piggin wrote:
@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
{
DEFINE_WAIT_BIT(wait, page-flags, PG_locked);
+ set_bit(PG_waiters, page-flags);
+ if (unlikely(!TestSetPageLocked(page))) {
What happens if another cpu is coming through
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
{
DEFINE_WAIT_BIT(wait, page-flags, PG_locked);
+ set_bit(PG_waiters, page-flags);
+ if (unlikely(!TestSetPageLocked(page))) {
What happens if another cpu is
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
- smp_mb__after_clear_bit();
-
Andrew Morton wrote:
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
-
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
[snip]
More on-topic, since you suggest doing more within vmtruncate_range
than the filesystem: no, I'm afraid that's misdesigned, and I want
to move almost all of it into the filesystem ->truncate_range.
Because, if what
On Wed, 2 May 2007, Nick Piggin wrote:
> Hugh Dickins wrote:
> >
> > But I was quite disappointed when
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix.patch
> > appeared, putting double unmap_mapping_range calls in. Certainly
> > you were wrong to take the one out, but a pity to end
Nick Piggin wrote:
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems
Nick Piggin wrote:
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems
On Wed, 2 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
But I was quite disappointed when
mm-fix-fault-vs-invalidate-race-for-linear-mappings-fix.patch
appeared, putting double unmap_mapping_range calls in. Certainly
you were wrong to take the one out, but a pity to end up with
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
[snip]
More on-topic, since you suggest doing more within vmtruncate_range
than the filesystem: no, I'm afraid that's misdesigned, and I want
to move almost all of it into the filesystem -truncate_range.
Because, if what
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems with performance.
On Tue, 1 May 2007, Nick Piggin wrote:
> Andrew Morton wrote:
>
> > mm-simplify-filemap_nopage.patch
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
> > mm-merge-nopfn-into-fault.patch
> >
On Tue, 01 May 2007 18:44:07 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > mm-simplify-filemap_nopage.patch
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
> > mm-merge-nopfn-into-fault.patch
> >
Andrew Morton wrote:
mm-simplify-filemap_nopage.patch
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-nopfn-into-fault.patch
convert-hugetlbfs-to-use-vm_ops-fault.patch
mm-remove-legacy-cruft.patch
Andrew Morton wrote:
mm-simplify-filemap_nopage.patch
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-nopfn-into-fault.patch
convert-hugetlbfs-to-use-vm_ops-fault.patch
mm-remove-legacy-cruft.patch
On Tue, 01 May 2007 18:44:07 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
mm-simplify-filemap_nopage.patch
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-nopfn-into-fault.patch
On Tue, 1 May 2007, Nick Piggin wrote:
Andrew Morton wrote:
mm-simplify-filemap_nopage.patch
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-nopfn-into-fault.patch
Hugh Dickins wrote:
On Tue, 1 May 2007, Nick Piggin wrote:
There were concerns that we could do this more cheaply, but I think it
is important to start with a base that is simple and more likely to
be correct and build on that. My testing didn't show any obvious
problems with performance.
46 matches
Mail list logo
