On Wed, 2005-02-02 at 14:09 +1100, Nick Piggin wrote:
> On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote:
> > On Wed, 2 Feb 2005, Nick Piggin wrote:
> > I mean we could just speculatively copy, risk copying crap and
> > discard that later when we find that the pte has changed. This
On Wed, 2005-02-02 at 14:09 +1100, Nick Piggin wrote:
On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote:
On Wed, 2 Feb 2005, Nick Piggin wrote:
I mean we could just speculatively copy, risk copying crap and
discard that later when we find that the pte has changed. This would
On Wed, 2 Feb 2005, Nick Piggin wrote:
> Well yeah, but the interesting case is when that isn't a lock ;)
>
> I'm not saying what you've got is no good. I'm sure it would be fine
> for testing. And if it happens that we can do the "page_count doesn't
> mean anything after it has reached zero and
On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote:
> On Wed, 2 Feb 2005, Nick Piggin wrote:
>
> > Well yeah, but the interesting case is when that isn't a lock ;)
> >
> > I'm not saying what you've got is no good. I'm sure it would be fine
> > for testing. And if it happens that we can
On Tue, 2005-02-01 at 17:20 -0800, Christoph Lameter wrote:
> On Wed, 2 Feb 2005, Nick Piggin wrote:
>
> > > The unmapping in rmap.c would change the pte. This would be discovered
> > > after acquiring the spinlock later in do_wp_page. Which would then lead to
> > > the operation being abandoned.
On Wed, 2 Feb 2005, Nick Piggin wrote:
> > The unmapping in rmap.c would change the pte. This would be discovered
> > after acquiring the spinlock later in do_wp_page. Which would then lead to
> > the operation being abandoned.
> Oh yes, but suppose your page_cache_get is happening at the same
On Tue, 2005-02-01 at 11:01 -0800, Christoph Lameter wrote:
> On Tue, 1 Feb 2005, Nick Piggin wrote:
> > A per-pte lock is sufficient for this case, of course, which is why the
> > pte-locked system is completely free of the page table lock.
>
> Introducing pte locking would allow us to go
On Tue, 1 Feb 2005, Nick Piggin wrote:
> > pte_unmap(page_table);
> > + page_table_atomic_stop(mm);
> >
> > /*
> > * Ok, we need to copy. Oh, well..
> > */
> > if (!PageReserved(old_page))
> > page_cache_get(old_page);
> > - spin_unlock(>page_table_lock);
> >
On Tue, 1 Feb 2005, Nick Piggin wrote:
> Slightly OT: are you still planning to move the update_mem_hiwater and
> friends crud out of these fastpaths? It looks like at least that function
> is unsafe to be lockless.
Yes. I have a patch pending and the author of the CSA patches is a
cowoerker of
On Tue, 1 Feb 2005, Nick Piggin wrote:
> Hmm, this is moving toward the direction my patches take.
You are right. But I am still weary of the transactional idea in your
patchset (which is really not comparable with a database transaction
after all...).
I think moving to cmpxchg and xchg
On Tue, 1 Feb 2005, Nick Piggin wrote:
Slightly OT: are you still planning to move the update_mem_hiwater and
friends crud out of these fastpaths? It looks like at least that function
is unsafe to be lockless.
Yes. I have a patch pending and the author of the CSA patches is a
cowoerker of
On Tue, 1 Feb 2005, Nick Piggin wrote:
pte_unmap(page_table);
+ page_table_atomic_stop(mm);
/*
* Ok, we need to copy. Oh, well..
*/
if (!PageReserved(old_page))
page_cache_get(old_page);
- spin_unlock(mm-page_table_lock);
I don't think
On Tue, 2005-02-01 at 11:01 -0800, Christoph Lameter wrote:
On Tue, 1 Feb 2005, Nick Piggin wrote:
A per-pte lock is sufficient for this case, of course, which is why the
pte-locked system is completely free of the page table lock.
Introducing pte locking would allow us to go further with
On Wed, 2 Feb 2005, Nick Piggin wrote:
The unmapping in rmap.c would change the pte. This would be discovered
after acquiring the spinlock later in do_wp_page. Which would then lead to
the operation being abandoned.
Oh yes, but suppose your page_cache_get is happening at the same time
as
On Tue, 2005-02-01 at 17:20 -0800, Christoph Lameter wrote:
On Wed, 2 Feb 2005, Nick Piggin wrote:
The unmapping in rmap.c would change the pte. This would be discovered
after acquiring the spinlock later in do_wp_page. Which would then lead to
the operation being abandoned.
Oh yes,
On Wed, 2 Feb 2005, Nick Piggin wrote:
Well yeah, but the interesting case is when that isn't a lock ;)
I'm not saying what you've got is no good. I'm sure it would be fine
for testing. And if it happens that we can do the page_count doesn't
mean anything after it has reached zero and been
On Tue, 1 Feb 2005, Nick Piggin wrote:
Hmm, this is moving toward the direction my patches take.
You are right. But I am still weary of the transactional idea in your
patchset (which is really not comparable with a database transaction
after all...).
I think moving to cmpxchg and xchg
On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote:
On Wed, 2 Feb 2005, Nick Piggin wrote:
Well yeah, but the interesting case is when that isn't a lock ;)
I'm not saying what you've got is no good. I'm sure it would be fine
for testing. And if it happens that we can do the
Christoph Lameter wrote:
The page fault handler attempts to use the page_table_lock only for short
time periods. It repeatedly drops and reacquires the lock. When the lock
is reacquired, checks are made if the underlying pte has changed before
replacing the pte value. These locations are a good
Christoph Lameter wrote:
Slightly OT: are you still planning to move the update_mem_hiwater and
friends crud out of these fastpaths? It looks like at least that function
is unsafe to be lockless.
@@ -1316,21 +1318,27 @@ static int do_wp_page(struct mm_struct *
Christoph Lameter wrote:
Slightly OT: are you still planning to move the update_mem_hiwater and
friends crud out of these fastpaths? It looks like at least that function
is unsafe to be lockless.
@@ -1316,21 +1318,27 @@ static int do_wp_page(struct mm_struct *
Christoph Lameter wrote:
The page fault handler attempts to use the page_table_lock only for short
time periods. It repeatedly drops and reacquires the lock. When the lock
is reacquired, checks are made if the underlying pte has changed before
replacing the pte value. These locations are a good
The page fault handler attempts to use the page_table_lock only for short
time periods. It repeatedly drops and reacquires the lock. When the lock
is reacquired, checks are made if the underlying pte has changed before
replacing the pte value. These locations are a good fit for the use of
The page fault handler attempts to use the page_table_lock only for short
time periods. It repeatedly drops and reacquires the lock. When the lock
is reacquired, checks are made if the underlying pte has changed before
replacing the pte value. These locations are a good fit for the use of
24 matches
Mail list logo
