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_highpa
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
clearmem_highp
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
> > > necessitat
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 p
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 th
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 infrastructu
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() i
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 dead
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 ti
* 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
* 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 kern
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, whic
* 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 repo
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 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 {
+
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 sta
* 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 "unsubs
* 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 syst
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.)
Numb
* 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
> >tra
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
25 matches
Mail list logo
