Hi,
On Mon, Feb 12, 2001 at 07:15:57PM -0800, george anzinger wrote:
> Excuse me if I am off base here, but wouldn't an atomic operation be
> better here. There are atomic inc/dec and add/sub macros for this. It
> just seems that that is all that is needed here (from inspection of the
>
Hi,
On Mon, Feb 12, 2001 at 07:15:57PM -0800, george anzinger wrote:
Excuse me if I am off base here, but wouldn't an atomic operation be
better here. There are atomic inc/dec and add/sub macros for this. It
just seems that that is all that is needed here (from inspection of the
patch).
On Mon, 12 Feb 2001, george anzinger wrote:
> Excuse me if I am off base here, but wouldn't an atomic operation be
> better here. There are atomic inc/dec and add/sub macros for this. It
> just seems that that is all that is needed here (from inspection of the
> patch).
Most functions which
Excuse me if I am off base here, but wouldn't an atomic operation be
better here. There are atomic inc/dec and add/sub macros for this. It
just seems that that is all that is needed here (from inspection of the
patch).
George
Rasmus Andersen wrote:
>
> On Mon, Jan 29, 2001 at 07:30:01PM
Excuse me if I am off base here, but wouldn't an atomic operation be
better here. There are atomic inc/dec and add/sub macros for this. It
just seems that that is all that is needed here (from inspection of the
patch).
George
Rasmus Andersen wrote:
On Mon, Jan 29, 2001 at 07:30:01PM
On Mon, 12 Feb 2001, george anzinger wrote:
Excuse me if I am off base here, but wouldn't an atomic operation be
better here. There are atomic inc/dec and add/sub macros for this. It
just seems that that is all that is needed here (from inspection of the
patch).
Most functions which
David Howells writes:
> Would it not be better to use some sort of atomic add/subtract/clear operation
> rather than a spinlock? (Which would also give you fewer atomic memory access
> cycles).
Please see older threads about this, it has been discussed to death
already (hint:
On Tue, Jan 30, 2001 at 08:18:56AM +, David Howells wrote:
> >...
> > + spin_lock(>page_table_lock);
> > mm->rss++;
> > + spin_unlock(>page_table_lock);
> >...
>
> Would it not be better to use some sort of atomic add/subtract/clear operation
> rather than a spinlock? (Which would
>...
> + spin_lock(>page_table_lock);
> mm->rss++;
> + spin_unlock(>page_table_lock);
>...
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give you fewer atomic memory access
cycles).
David
-
To unsubscribe
...
+ spin_lock(mm-page_table_lock);
mm-rss++;
+ spin_unlock(mm-page_table_lock);
...
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give you fewer atomic memory access
cycles).
David
-
To unsubscribe
On Tue, Jan 30, 2001 at 08:18:56AM +, David Howells wrote:
...
+ spin_lock(mm-page_table_lock);
mm-rss++;
+ spin_unlock(mm-page_table_lock);
...
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give
David Howells writes:
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give you fewer atomic memory access
cycles).
Please see older threads about this, it has been discussed to death
already (hint: sizeof(atomic_t),
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
> On Mon, Jan 29, 2001 at 07:30:01PM -0200, Rik van Riel wrote:
> > On Mon, 29 Jan 2001, Rasmus Andersen wrote:
> >
> > > Please comment. Or else I will continue to sumbit it :)
> >
> > The following will hang the kernel on SMP, since you're
> >
On Mon, Jan 29, 2001 at 07:30:01PM -0200, Rik van Riel wrote:
> On Mon, 29 Jan 2001, Rasmus Andersen wrote:
>
> > Please comment. Or else I will continue to sumbit it :)
>
> The following will hang the kernel on SMP, since you're
> already holding the spinlock here. Try compiling with
>
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
> Please comment. Or else I will continue to sumbit it :)
The following will hang the kernel on SMP, since you're
already holding the spinlock here. Try compiling with
CONFIG_SMP and see what happens...
> diff -aur linux-2.4.1-pre11-clean/mm/vmscan.c
Hi.
This patch tries to fix the potential rss accounting race where we
fiddle with mm->rss without holding the page_table_lock.
In addition to the places this patch touches there are some places
in fs/ where mm->rss is touched. But I am not sure of the finer
points of this code, so perhaps
Hi.
This patch tries to fix the potential rss accounting race where we
fiddle with mm-rss without holding the page_table_lock.
In addition to the places this patch touches there are some places
in fs/ where mm-rss is touched. But I am not sure of the finer
points of this code, so perhaps
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
Please comment. Or else I will continue to sumbit it :)
The following will hang the kernel on SMP, since you're
already holding the spinlock here. Try compiling with
CONFIG_SMP and see what happens...
diff -aur linux-2.4.1-pre11-clean/mm/vmscan.c
On Mon, Jan 29, 2001 at 07:30:01PM -0200, Rik van Riel wrote:
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
Please comment. Or else I will continue to sumbit it :)
The following will hang the kernel on SMP, since you're
already holding the spinlock here. Try compiling with
CONFIG_SMP and
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
On Mon, Jan 29, 2001 at 07:30:01PM -0200, Rik van Riel wrote:
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
Please comment. Or else I will continue to sumbit it :)
The following will hang the kernel on SMP, since you're
already holding the
20 matches
Mail list logo
