On Fri, Feb 02, 2007 at 01:24:40PM -0600, Matt Mackall wrote:
> On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
> > On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
> > > > Yup. Even better, use clear_highpage().
> > >
> > > For even more goodness,
On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
> On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
> > > Yup. Even better, use clear_highpage().
> >
> > For even more goodness, clearmem_highpage_flush() does exactly
> > the right thing for partial page zeroing ;)
On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
> On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
> > > Yup. Even better, use clear_highpage().
> >
> > For even more goodness, clearmem_highpage_flush() does exactly
> > the right thing for partial page zeroing ;)
On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
> > Yup. Even better, use clear_highpage().
>
> For even more goodness, clearmem_highpage_flush() does exactly
> the right thing for partial page zeroing ;)
Note that there are tons of places in buffer.c that could use
On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
Yup. Even better, use clear_highpage().
For even more goodness, clearmem_highpage_flush() does exactly
the right thing for partial page zeroing ;)
Note that there are tons of places in buffer.c that could use
On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
Yup. Even better, use clear_highpage().
For even more goodness, clearmem_highpage_flush() does exactly
the right thing for partial page zeroing ;)
Note
On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
Yup. Even better, use clear_highpage().
For even more goodness, clearmem_highpage_flush() does exactly
the right thing for partial page zeroing ;)
Note
On Fri, Feb 02, 2007 at 01:24:40PM -0600, Matt Mackall wrote:
On Fri, Feb 02, 2007 at 12:05:11PM +, Christoph Hellwig wrote:
On Wed, Jan 31, 2007 at 02:22:24PM +1100, David Chinner wrote:
Yup. Even better, use clear_highpage().
For even more goodness, clearmem_highpage_flush()
On Tue, Jan 30, 2007 at 05:11:32PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 11:44:36 +1100
> David Chinner <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
> > > We still don't know what is the source of kmap() activity which
> > >
On Wed, 31 Jan 2007 11:44:36 +1100
David Chinner <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
> > We still don't know what is the source of kmap() activity which
> > necessitated this patch btw. AFAIK the busiest source is ext2 directories,
> > but
On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
> We still don't know what is the source of kmap() activity which
> necessitated this patch btw. AFAIK the busiest source is ext2 directories,
> but perhaps NFS under certain conditions?
>
>
>
> ->prepare_write no longer requires
On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
We still don't know what is the source of kmap() activity which
necessitated this patch btw. AFAIK the busiest source is ext2 directories,
but perhaps NFS under certain conditions?
looks at xfs_iozero
-prepare_write no longer
On Wed, 31 Jan 2007 11:44:36 +1100
David Chinner [EMAIL PROTECTED] wrote:
On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
We still don't know what is the source of kmap() activity which
necessitated this patch btw. AFAIK the busiest source is ext2 directories,
but perhaps
On Tue, Jan 30, 2007 at 05:11:32PM -0800, Andrew Morton wrote:
On Wed, 31 Jan 2007 11:44:36 +1100
David Chinner [EMAIL PROTECTED] wrote:
On Mon, Jan 29, 2007 at 06:15:57PM -0800, Andrew Morton wrote:
We still don't know what is the source of kmap() activity which
necessitated this
On Mon, 29 Jan 2007 17:49:14 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 29 Jan 2007 17:31:20 -0800
> > "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> >
> >> Peter Zijlstra wrote:
> >>> On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
> >>>
>
Ingo Molnar wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought, so
we might as well make it work better. Both HIGHMEM and HIGHPTE is the
default on many distro kernels, which pushes the kmap
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap()
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
> Peter Zijlstra wrote:
> > On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
> >
> >> As Christoph says, it's very much preferred that code be migrated over to
> >> kmap_atomic(). Partly because kmap() is
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Here are the numbers that i think changes the picture:
i forgot to explain them:
current (estimated) total installed base of 32-bit (i686) Fedora:
> http://www.fedoraproject.org/awstats/stats/updates-released-fc6-i386.total
current (estimated)
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > For every 64-bit Fedora box there's more than seven 32-bit boxes. I
> > think 32-bit is going to live with us far longer than many thought,
> > so we might as well make it work better. Both HIGHMEM and HIGHPTE is
> > the default on many distro
On Mon, 29 Jan 2007, Ingo Molnar wrote:
>
> For every 64-bit Fedora box there's more than seven 32-bit boxes. I
> think 32-bit is going to live with us far longer than many thought, so
> we might as well make it work better. Both HIGHMEM and HIGHPTE is the
> default on many distro kernels,
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Eradicate global locks.
> >
> > - kmap_lock is removed by extensive use of atomic_t, a new flush
> >scheme and modifying set_page_address to only allow NULL<->virt
> >transitions.
> I really don't recall any performance problems being
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
> As Christoph says, it's very much preferred that code be migrated over to
> kmap_atomic(). Partly because kmap() is deadlockable in situations where a
> large number of threads are trying to take two kmaps at the same time and
> we run
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same time and
we run out.
* Andrew Morton [EMAIL PROTECTED] wrote:
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL-virt
transitions.
I really don't recall any performance problems being reported out of
On Mon, 29 Jan 2007, Ingo Molnar wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought, so
we might as well make it work better. Both HIGHMEM and HIGHPTE is the
default on many distro kernels, which
* Hugh Dickins [EMAIL PROTECTED] wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought,
so we might as well make it work better. Both HIGHMEM and HIGHPTE is
the default on many distro kernels,
* Ingo Molnar [EMAIL PROTECTED] wrote:
Here are the numbers that i think changes the picture:
i forgot to explain them:
current (estimated) total installed base of 32-bit (i686) Fedora:
http://www.fedoraproject.org/awstats/stats/updates-released-fc6-i386.total
current (estimated) total
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same
On Mon, 29 Jan 2007 17:31:20 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is
Ingo Molnar wrote:
For every 64-bit Fedora box there's more than seven 32-bit boxes. I
think 32-bit is going to live with us far longer than many thought, so
we might as well make it work better. Both HIGHMEM and HIGHPTE is the
default on many distro kernels, which pushes the kmap
On Mon, 29 Jan 2007 17:49:14 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very
Andrew Morton wrote:
On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
+static inline int set_page_address(struct page *page, void *address)
+{
+ if (address)
+ return cmpxchg(>virtual, NULL, address) == NULL;
+ else {
+ /*
+
On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Eradicate global locks.
>
> - kmap_lock is removed by extensive use of atomic_t, a new flush
>scheme and modifying set_page_address to only allow NULL<->virt
>transitions.
>
> A count of 0 is an exclusive
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 04:48:06PM +0100, Ingo Molnar wrote:
> > i'm sorry, but do you realize that files_lock is a global lock,
> > triggered by /every single/ file close?
>
> Please check which thread you're in before you start such lengthy
>
On Sun, Jan 28, 2007 at 04:48:06PM +0100, Ingo Molnar wrote:
> i'm sorry, but do you realize that files_lock is a global lock,
> triggered by /every single/ file close?
Please check which thread you're in before you start such lengthy rants.
-
To unsubscribe from this list: send the line
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 04:17:00PM +0100, Ingo Molnar wrote:
> > scalability. I did lock profiling on the -rt kernel, which exposes
> > such things nicely. Half of the lock contention events during kernel
> > compile were due to kmap(). (The
On Sun, Jan 28, 2007 at 04:17:00PM +0100, Ingo Molnar wrote:
> scalability. I did lock profiling on the -rt kernel, which exposes such
> things nicely. Half of the lock contention events during kernel compile
> were due to kmap(). (The system had 2 GB of RAM, so 40% lowmem, 60%
> highmem.)
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 03:11:34PM +0100, Peter Zijlstra wrote:
> > Eradicate global locks.
> >
> > - kmap_lock is removed by extensive use of atomic_t, a new flush
> >scheme and modifying set_page_address to only allow NULL<->virt
> >
On Sun, Jan 28, 2007 at 03:11:34PM +0100, Peter Zijlstra wrote:
> Eradicate global locks.
>
> - kmap_lock is removed by extensive use of atomic_t, a new flush
>scheme and modifying set_page_address to only allow NULL<->virt
>transitions.
What's the point for this? Extensive atomic_t
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL<->virt
transitions.
A count of 0 is an exclusive state acting as an entry lock. This is done
using inc_not_zero and cmpxchg. The restriction on
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL-virt
transitions.
A count of 0 is an exclusive state acting as an entry lock. This is done
using inc_not_zero and cmpxchg. The restriction on
On Sun, Jan 28, 2007 at 03:11:34PM +0100, Peter Zijlstra wrote:
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL-virt
transitions.
What's the point for this? Extensive atomic_t use is
* Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 28, 2007 at 03:11:34PM +0100, Peter Zijlstra wrote:
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL-virt
transitions.
On Sun, Jan 28, 2007 at 04:17:00PM +0100, Ingo Molnar wrote:
scalability. I did lock profiling on the -rt kernel, which exposes such
things nicely. Half of the lock contention events during kernel compile
were due to kmap(). (The system had 2 GB of RAM, so 40% lowmem, 60%
highmem.)
Numbers
* Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 28, 2007 at 04:17:00PM +0100, Ingo Molnar wrote:
scalability. I did lock profiling on the -rt kernel, which exposes
such things nicely. Half of the lock contention events during kernel
compile were due to kmap(). (The system had 2
On Sun, Jan 28, 2007 at 04:48:06PM +0100, Ingo Molnar wrote:
i'm sorry, but do you realize that files_lock is a global lock,
triggered by /every single/ file close?
Please check which thread you're in before you start such lengthy rants.
-
To unsubscribe from this list: send the line
* Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 28, 2007 at 04:48:06PM +0100, Ingo Molnar wrote:
i'm sorry, but do you realize that files_lock is a global lock,
triggered by /every single/ file close?
Please check which thread you're in before you start such lengthy
rants.
On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
Eradicate global locks.
- kmap_lock is removed by extensive use of atomic_t, a new flush
scheme and modifying set_page_address to only allow NULL-virt
transitions.
A count of 0 is an exclusive state acting
Andrew Morton wrote:
On Sun, 28 Jan 2007 15:11:34 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
+static inline int set_page_address(struct page *page, void *address)
+{
+ if (address)
+ return cmpxchg(page-virtual, NULL, address) == NULL;
+ else {
+ /*
52 matches
Mail list logo
