On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
> Nick Piggin wrote:
> >Hi guys,
> >
> >I'd like to finally remove nopfn from the tree. So I would really like to
> >get
> >this patch into -mm soon (or broken out patches into appropriate trees).
>
On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
Nick Piggin wrote:
Hi guys,
I'd like to finally remove nopfn from the tree. So I would really like to
get
this patch into -mm soon (or broken out patches into appropriate trees).
Anyway, I don't have a good way to compile
On Wednesday 09 January 2008 19:52, Jens Axboe wrote:
> So how does it work? Instead of punting IO to a thread and passing it
> through the page cache, we instead attempt to send the IO directly to the
> filesystem block that it maps to.
You told Christoph that just using direct-IO from kernel
On Thursday 10 January 2008 02:45, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > It is to make everybody happy. Especially in code that everyone works
> > on like mm/ and fs/, you can't just have everybody following their own
> > slightly different c
On Thursday 10 January 2008 02:45, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
It is to make everybody happy. Especially in code that everyone works
on like mm/ and fs/, you can't just have everybody following their own
slightly different conventions.
Conventions are what
On Wednesday 09 January 2008 19:52, Jens Axboe wrote:
So how does it work? Instead of punting IO to a thread and passing it
through the page cache, we instead attempt to send the IO directly to the
filesystem block that it maps to.
You told Christoph that just using direct-IO from kernel
On Wednesday 09 January 2008 10:51, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > No. I mean call the bit PG_private2. That way non-pagecache and
> > > > filesystems that d
s,
Nick
>
> Dave.
>
> >
> > Anyway, please apply.
> >
> > --
> >
> > drm: nopage
> >
> > Convert drm from nopage to fault.
> > Remove redundant vma range checks.
> >
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
, they will be easier to fix. More
problematic
is actually testing the things; I'm not even sure I'm covering all bases with
drm testing.
So, if I could trouble you for a quick review and/or test at some time the
patch is against latest -mm.
Thanks,
Nick
---
From: Nick Piggin <[EMAIL PROTECTED]>
Reimp
for it in the
core mm code and documentation (and a few stray references to it in comments).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
Documentation/feature-removal-schedule.txt |9
Documentation/filesystems/Locking
redundant vma range checks.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/char/drm/drm_vm.c | 131 +-
1 file changed, 61 insertions(+), 70 deletions(-)
Index: linux-2.6/drivers/ch
redundant vma range checks.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/char/drm/drm_vm.c | 131 +-
1 file changed, 61 insertions(+), 70 deletions(-)
Index: linux-2.6/drivers/char/drm
for it in the
core mm code and documentation (and a few stray references to it in comments).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
Documentation/feature-removal-schedule.txt |9
Documentation/filesystems/Locking |3
, they will be easier to fix. More
problematic
is actually testing the things; I'm not even sure I'm covering all bases with
drm testing.
So, if I could trouble you for a quick review and/or test at some time the
patch is against latest -mm.
Thanks,
Nick
---
From: Nick Piggin [EMAIL PROTECTED]
Reimplement
Convert drm from nopage to fault.
Remove redundant vma range checks.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Wednesday 09 January 2008 10:51, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
No. I mean call the bit PG_private2. That way non-pagecache and
filesystems that don't use fscache can use it.
The bit is called PG_owner_priv_2
On Tuesday 08 January 2008 16:44, H. Peter Anvin wrote:
> Nick Piggin wrote:
> > On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
> >> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical
> >> OR
> >>
> >> @@ -450,9 +450,
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
>
> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
>
> static inline int free_pages_check(struct page *page)
> {
> - if
On Tuesday 08 January 2008 00:09, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > No. I mean call the bit PG_private2. That way non-pagecache and
> > filesystems that don't use fscache can use it.
>
> The bit is called PG_owner_priv_2, and then 'subcla
On Thursday 03 January 2008 03:27, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Then make a PG_private2 bit and use that.
>
> To what end? Are you suggesting I should have:
>
> PG_private2 = PG_private | PG_fscache
No. I mean call the bi
On Thursday 03 January 2008 19:55, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Have you done anything more with allowing > 256 CPUS in this
> > > spinlock patch? We've been testing with 1k cpus and to verify with
> > > -mm kern
On Thursday 03 January 2008 19:55, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Have you done anything more with allowing 256 CPUS in this
spinlock patch? We've been testing with 1k cpus and to verify with
-mm kernel, we need to unpatch these spinlock changes.
Hi Mike
On Thursday 03 January 2008 03:27, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Then make a PG_private2 bit and use that.
To what end? Are you suggesting I should have:
PG_private2 = PG_private | PG_fscache
No. I mean call the bit PG_private2. That way non-pagecache
On Tuesday 08 January 2008 00:09, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
No. I mean call the bit PG_private2. That way non-pagecache and
filesystems that don't use fscache can use it.
The bit is called PG_owner_priv_2, and then 'subclassed' to PG_fscache,
much like
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int free_pages_check(struct page *page)
{
- if (unlikely(page_mapcount(page) |
On Tuesday 08 January 2008 16:44, H. Peter Anvin wrote:
Nick Piggin wrote:
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical
OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int
On Saturday 05 January 2008 14:25, Linda Walsh wrote:
> A question that comes to mind every time I go through the settings
> for "Preemption Model" and "Preempt The Big Kernel Lock".
>
> Do each of the combinations "make sense", or are some "no-ops"?
> For model, we have 1) no forced (server), 2)
On Saturday 05 January 2008 14:25, Linda Walsh wrote:
A question that comes to mind every time I go through the settings
for Preemption Model and Preempt The Big Kernel Lock.
Do each of the combinations make sense, or are some no-ops?
For model, we have 1) no forced (server), 2) Voluntary
On Thursday 03 January 2008 10:35, Mike Travis wrote:
> Hi Nick,
>
> Have you done anything more with allowing > 256 CPUS in this spinlock
> patch? We've been testing with 1k cpus and to verify with -mm kernel,
> we need to "unpatch" these spinlock changes.
>
> Thanks,
> Mike
Hi Mike,
Actually
On Wednesday 02 January 2008 22:01, Peter Zijlstra wrote:
> On Wed, 2008-01-02 at 21:31 +1100, Nick Piggin wrote:
> > On Monday 31 December 2007 00:10, Ingo Molnar wrote:
> > > * Herbert Xu <[EMAIL PROTECTED]> wrote:
> > > > > Ingo, it's not good
On Monday 31 December 2007 00:10, Ingo Molnar wrote:
> * Herbert Xu <[EMAIL PROTECTED]> wrote:
> > > Ingo, it's not good that we have cond_resched() definitions
> > > conditionally duplicated in kernel.h - that's increasing the risk of
> > > bugs like this one.
> >
> > Actually, why do we even
On Monday 31 December 2007 00:10, Ingo Molnar wrote:
* Herbert Xu [EMAIL PROTECTED] wrote:
Ingo, it's not good that we have cond_resched() definitions
conditionally duplicated in kernel.h - that's increasing the risk of
bugs like this one.
Actually, why do we even have cond_resched
On Wednesday 02 January 2008 22:01, Peter Zijlstra wrote:
On Wed, 2008-01-02 at 21:31 +1100, Nick Piggin wrote:
On Monday 31 December 2007 00:10, Ingo Molnar wrote:
* Herbert Xu [EMAIL PROTECTED] wrote:
Ingo, it's not good that we have cond_resched() definitions
conditionally
On Thursday 03 January 2008 10:35, Mike Travis wrote:
Hi Nick,
Have you done anything more with allowing 256 CPUS in this spinlock
patch? We've been testing with 1k cpus and to verify with -mm kernel,
we need to unpatch these spinlock changes.
Thanks,
Mike
Hi Mike,
Actually I had it in
On Wed, Dec 26, 2007 at 09:21:58PM -0500, Joseph Fannin wrote:
> On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> >
>
> This doesn't build on powerpc with my .config:
>
> In file
On Wed, Dec 26, 2007 at 09:21:58PM -0500, Joseph Fannin wrote:
On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
This doesn't build on powerpc with my .config:
In file included from
On Saturday 22 December 2007 01:17, Rik van Riel wrote:
> On Fri, 21 Dec 2007 21:52:19 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > BTW. if you have any workloads that are limited by page reclaim,
> > especially unmapped file backed pagecache reclaim, then I
On Saturday 22 December 2007 01:17, Rik van Riel wrote:
On Fri, 21 Dec 2007 21:52:19 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
BTW. if you have any workloads that are limited by page reclaim,
especially unmapped file backed pagecache reclaim, then I have some
stright-line-speedup patches
On Friday 21 December 2007 07:56, Rik van Riel wrote:
> On Wed, 19 Dec 2007 11:04:26 -0500
>
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-12-19 at 08:45 -0500, Rik van Riel wrote:
> > > On Wed, 19 Dec 2007 11:56:48 +1100
> > >
>
On Friday 21 December 2007 07:56, Rik van Riel wrote:
On Wed, 19 Dec 2007 11:04:26 -0500
Lee Schermerhorn [EMAIL PROTECTED] wrote:
On Wed, 2007-12-19 at 08:45 -0500, Rik van Riel wrote:
On Wed, 19 Dec 2007 11:56:48 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Hmm, I still don't
On Friday 21 December 2007 06:24, Linus Torvalds wrote:
> On Thu, 20 Dec 2007, Jan Kara wrote:
> > As I wrote in my previous email, this solution works but hides the
> > fact that the page really *has* dirty data in it and *is* pinned in
> > memory until the commit code gets to writing it. So in
On Friday 21 December 2007 05:49, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > This reintroduces the fault vs truncate race window, which must be
> > > > fixed.
> > >
&g
On Friday 21 December 2007 05:33, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > I'd much prefer if you would handle this in the filesystem, and have
> > > > it set PG_private whenever fscache needs to receive a callback, and
> > >
On Thursday 20 December 2007 18:04, Christoph Lameter wrote:
> > The only reason the x86 ticket locks have the 256 CPu limit is that
> > if they go any bigger, we can't use the partial registers so would
> > have to have a few more instructions.
>
> x86_64 is going up to 4k or 16k cpus soon for
On Thursday 20 December 2007 18:04, Christoph Lameter wrote:
The only reason the x86 ticket locks have the 256 CPu limit is that
if they go any bigger, we can't use the partial registers so would
have to have a few more instructions.
x86_64 is going up to 4k or 16k cpus soon for our new
On Friday 21 December 2007 05:33, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
I'd much prefer if you would handle this in the filesystem, and have
it set PG_private whenever fscache needs to receive a callback, and
DTRT depending on whether PG_fscache etc. is set
On Friday 21 December 2007 05:49, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
This reintroduces the fault vs truncate race window, which must be
fixed.
Hmmm... perhaps.
What do you mean by perhaps?
I mean 'perhaps'. I'm
On Friday 21 December 2007 06:24, Linus Torvalds wrote:
On Thu, 20 Dec 2007, Jan Kara wrote:
As I wrote in my previous email, this solution works but hides the
fact that the page really *has* dirty data in it and *is* pinned in
memory until the commit code gets to writing it. So in theory
On Thursday 20 December 2007 12:05, Jan Kara wrote:
> > On Sun, 16 Dec 2007, Krzysztof Oledzki wrote:
> > > I'll confirm this tomorrow but it seems that even switching to
> > > data=ordered (AFAIK default o ext3) is indeed enough to cure this
> > > problem.
> >
> > Ok, do we actually have any ext3
On Thursday 20 December 2007 06:28, Peter Zijlstra wrote:
> On Wed, 2007-12-19 at 11:53 -0500, Lee Schermerhorn wrote:
> > On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote:
> > > On Wed, 19 Dec 2007 10:52:09 -0500
> > >
> > > Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> > > > I keep these
On Thursday 20 December 2007 00:45, Rik van Riel wrote:
> On Wed, 19 Dec 2007 11:56:48 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
> > > Rework of a patch by Nick Piggin -- part 1 of 2.
> > >
&
On Thursday 20 December 2007 00:45, Rik van Riel wrote:
On Wed, 19 Dec 2007 11:56:48 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
Rework of a patch by Nick Piggin -- part 1 of 2.
This patch:
1) defines the [CONFIG_
On Thursday 20 December 2007 06:28, Peter Zijlstra wrote:
On Wed, 2007-12-19 at 11:53 -0500, Lee Schermerhorn wrote:
On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote:
On Wed, 19 Dec 2007 10:52:09 -0500
Lee Schermerhorn [EMAIL PROTECTED] wrote:
I keep these patches up to date
On Thursday 20 December 2007 12:05, Jan Kara wrote:
On Sun, 16 Dec 2007, Krzysztof Oledzki wrote:
I'll confirm this tomorrow but it seems that even switching to
data=ordered (AFAIK default o ext3) is indeed enough to cure this
problem.
Ok, do we actually have any ext3 expert
On Tue, Dec 18, 2007 at 10:05:19PM +, Hugh Dickins wrote:
> Nick has observed that shmem.c still uses GFP_ATOMIC when adding to page
> cache or swap cache, without any radix tree preload: so tending to deplete
> emergency reserves of memory.
>
> GFP_ATOMIC remains appropriate in
; static, so there's no interface confusion to worry about.
>
> And lose that inappropriate "Anon pages are already on the LRU" comment
> in the merging: they're not already on the LRU, as Nick Piggin noticed.
>
> Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
No pr
On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
> Rework of a patch by Nick Piggin -- part 1 of 2.
>
> This patch:
>
> 1) defines the [CONFIG_]NORECLAIM_MLOCK sub-option and the
>stub version of the mlock/noreclaim APIs when it's
>not configured. Depends
On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
> I have seen soft cpu lockups in page_referenced_file() due to
> contention on i_mmap_lock() for different pages. Making the
> i_mmap_lock a reader/writer lock should increase parallelism
> in vmscan for file back pages mapped into many
On Tue, Dec 18, 2007 at 07:50:33PM +0800, Fengguang Wu wrote:
> On Tue, Dec 18, 2007 at 09:19:07AM +0100, Nick Piggin wrote:
> > On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
>
> > > + read_lock_irq(>tree_lock);
> > > + page = rad
On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
> @@ -1321,78 +1401,69 @@ int filemap_fault(struct vm_area_struct
> struct address_space *mapping = file->f_mapping;
> struct file_ra_state *ra = >f_ra;
> struct inode *inode = mapping->host;
> + pgoff_t offset =
On Tue, Dec 18, 2007 at 08:44:40AM +0100, Jens Axboe wrote:
> On Sat, Dec 15 2007, Nick Piggin wrote:
> > Hi,
> >
> > This is just an idea I had, which might make request processing a little
> > bit cheaper depending on queue behaviour. For example if it is getting
On Tue, Dec 18, 2007 at 08:44:40AM +0100, Jens Axboe wrote:
On Sat, Dec 15 2007, Nick Piggin wrote:
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting
plugged
unplugged frequently (as I
On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
@@ -1321,78 +1401,69 @@ int filemap_fault(struct vm_area_struct
struct address_space *mapping = file-f_mapping;
struct file_ra_state *ra = file-f_ra;
struct inode *inode = mapping-host;
+ pgoff_t offset =
On Tue, Dec 18, 2007 at 07:50:33PM +0800, Fengguang Wu wrote:
On Tue, Dec 18, 2007 at 09:19:07AM +0100, Nick Piggin wrote:
On Sun, Dec 16, 2007 at 07:59:30PM +0800, Fengguang Wu wrote:
+ read_lock_irq(mapping-tree_lock);
+ page = radix_tree_lookup(mapping-page_tree, offset
On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
I have seen soft cpu lockups in page_referenced_file() due to
contention on i_mmap_lock() for different pages. Making the
i_mmap_lock a reader/writer lock should increase parallelism
in vmscan for file back pages mapped into many
On Wednesday 19 December 2007 08:15, Rik van Riel wrote:
Rework of a patch by Nick Piggin -- part 1 of 2.
This patch:
1) defines the [CONFIG_]NORECLAIM_MLOCK sub-option and the
stub version of the mlock/noreclaim APIs when it's
not configured. Depends on [CONFIG_]NORECLAIM.
2) add
no interface confusion to worry about.
And lose that inappropriate Anon pages are already on the LRU comment
in the merging: they're not already on the LRU, as Nick Piggin noticed.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
No problems with me. Actually it is nice to make
On Tue, Dec 18, 2007 at 10:05:19PM +, Hugh Dickins wrote:
Nick has observed that shmem.c still uses GFP_ATOMIC when adding to page
cache or swap cache, without any radix tree preload: so tending to deplete
emergency reserves of memory.
GFP_ATOMIC remains appropriate in shmem_writepage's
On Tuesday 18 December 2007 09:54, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > This reintroduces the fault vs truncate race window, which must be fixed.
>
> Hmmm... perhaps.
What do you mean by perhaps?
> I remember that cropped up in NFS, but I
On Tuesday 18 December 2007 09:42, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > This is pretty nasty.
>
> Why? If the fs doesn't set PG_private or PG_fscache on any pages before
> calling read_cache_pages(), there's no difference.
It is conceptuall
On Tuesday 18 December 2007 09:36, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > I'd much prefer if you would handle this in the filesystem, and have it
> > set PG_private whenever fscache needs to receive a callback, and DTRT
> > depending on whe
On Tuesday 18 December 2007 09:36, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
I'd much prefer if you would handle this in the filesystem, and have it
set PG_private whenever fscache needs to receive a callback, and DTRT
depending on whether PG_fscache etc. is set
On Tuesday 18 December 2007 09:42, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
This is pretty nasty.
Why? If the fs doesn't set PG_private or PG_fscache on any pages before
calling read_cache_pages(), there's no difference.
It is conceptually wrong.
Furthermore
On Tuesday 18 December 2007 09:54, David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
This reintroduces the fault vs truncate race window, which must be fixed.
Hmmm... perhaps.
What do you mean by perhaps?
I remember that cropped up in NFS, but I'm doing things
a bit differently
Introduce queue_ accessors to set and clear queue_flags, which include debug
checks to ensure queue_lock is held. Non-checking versions are provided where
it is known that there can be no parallelism on queue_flags.
Index: linux-2.6/block/elevator.c
All queue_flag manipulations are performed under queue_lock (or eg. during
allocation-time where parallelism isn't a problem). So we can use non-atomic
bitops for these.
Index: linux-2.6/block/elevator.c
===
---
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting plugged
unplugged frequently (as I think is the case for some database workloads),
then we might save one or two atomic operations per request.
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting plugged
unplugged frequently (as I think is the case for some database workloads),
then we might save one or two atomic operations per request.
All queue_flag manipulations are performed under queue_lock (or eg. during
allocation-time where parallelism isn't a problem). So we can use non-atomic
bitops for these.
Index: linux-2.6/block/elevator.c
===
---
Introduce queue_ accessors to set and clear queue_flags, which include debug
checks to ensure queue_lock is held. Non-checking versions are provided where
it is known that there can be no parallelism on queue_flags.
Index: linux-2.6/block/elevator.c
On Thursday 06 December 2007 06:40, David Howells wrote:
> Add a function - cancel_rejected_write() - to excise a rejected write from
> the pagecache. This function is related to the truncation family of
> routines. It permits the pages modified by a network filesystem client
> (such as AFS) to
On Thursday 06 December 2007 06:39, David Howells wrote:
> Recruit a couple of page flags to aid in cache management. The following
> extra flags are defined:
>
> (1) PG_fscache (PG_owner_priv_2)
>
> The marked page is backed by a local cache and is pinning resources in
> the cache driver.
On Thursday 06 December 2007 06:39, David Howells wrote:
> The attached patch causes read_cache_pages() to release page-private data
> on a page for which add_to_page_cache() fails or the filler function fails.
> This permits pages with caching references associated with them to be
> cleaned up.
>
On Friday 14 December 2007 02:24, Erez Zadok wrote:
> In message <[EMAIL PROTECTED]>, Nick Piggin writes:
> > On Monday 10 December 2007 13:42, Erez Zadok wrote:
> > > Needed to maintain cache coherency after branch management.
> >
> > Hmm,
On Friday 14 December 2007 02:24, Erez Zadok wrote:
In message [EMAIL PROTECTED], Nick Piggin writes:
On Monday 10 December 2007 13:42, Erez Zadok wrote:
Needed to maintain cache coherency after branch management.
Hmm, I'd much prefer to be able to sleep in invalidate_mapping_pages
On Thursday 06 December 2007 06:39, David Howells wrote:
The attached patch causes read_cache_pages() to release page-private data
on a page for which add_to_page_cache() fails or the filler function fails.
This permits pages with caching references associated with them to be
cleaned up.
The
On Thursday 06 December 2007 06:39, David Howells wrote:
Recruit a couple of page flags to aid in cache management. The following
extra flags are defined:
(1) PG_fscache (PG_owner_priv_2)
The marked page is backed by a local cache and is pinning resources in
the cache driver.
(2)
On Thursday 06 December 2007 06:40, David Howells wrote:
Add a function - cancel_rejected_write() - to excise a rejected write from
the pagecache. This function is related to the truncation family of
routines. It permits the pages modified by a network filesystem client
(such as AFS) to be
On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
> On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
> > On Tuesday 11 December 2007 08:30, Dave Kleikamp wrote:
> > > Nick,
> > > I've played with the fast_gup patch a bit. I was able to find a
> >
On Monday 10 December 2007 13:42, Erez Zadok wrote:
> Needed to maintain cache coherency after branch management.
>
Hmm, I'd much prefer to be able to sleep in invalidate_mapping_pages
before this function gets exported.
As it is, it can cause massive latencies on preemption and the inode_lock
On Tuesday 11 December 2007 08:30, Dave Kleikamp wrote:
> On Mon, 2007-10-15 at 22:25 +1000, Nick Piggin wrote:
> > On Monday 15 October 2007 04:19, Siddha, Suresh B wrote:
> > > On Sun, Oct 14, 2007 at 11:01:02AM +1000, Nick Piggin wrote:
> > > > This is just a r
eel a
> lot better about this that way :-) I do have the feeling that it makes
> printk printout a lot more robust in general, independently of the
> cpu_clock() change - especially with more complex consoles like
> netconsole or fbcon.
Reviewed-by: Nick Piggin <[EMAIL PROTECTED]&g
flush_dcache_page(page);
>
> I asked myself why this problem never happened before. So I asked our testers
> to reproduce this problem on 2.6.23 and service levels. As the testcase did
> not trigger, I looked into the 2.6.23 code. This problem was introduced by
> comm
to reproduce this problem on 2.6.23 and service levels. As the testcase did
not trigger, I looked into the 2.6.23 code. This problem was introduced by
commit 4a9e5ef1f4f15205e477817a5cefc34bd3f65f55 (mm: write iovec cleanup from
Nick Piggin) during 2.6.24-rc:
snip---
- copied
this that way :-) I do have the feeling that it makes
printk printout a lot more robust in general, independently of the
cpu_clock() change - especially with more complex consoles like
netconsole or fbcon.
Reviewed-by: Nick Piggin [EMAIL PROTECTED]
for both of them. However I don't feel good to get
On Tuesday 11 December 2007 08:30, Dave Kleikamp wrote:
On Mon, 2007-10-15 at 22:25 +1000, Nick Piggin wrote:
On Monday 15 October 2007 04:19, Siddha, Suresh B wrote:
On Sun, Oct 14, 2007 at 11:01:02AM +1000, Nick Piggin wrote:
This is just a really quick hack, untested ATM, but one
On Monday 10 December 2007 13:42, Erez Zadok wrote:
Needed to maintain cache coherency after branch management.
Hmm, I'd much prefer to be able to sleep in invalidate_mapping_pages
before this function gets exported.
As it is, it can cause massive latencies on preemption and the inode_lock
so
On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
On Tuesday 11 December 2007 08:30, Dave Kleikamp wrote:
Nick,
I've played with the fast_gup patch a bit. I was able to find a
problem in follow_hugetlb_page() that Adam
On Saturday 08 December 2007 11:50, Nick Piggin wrote:
> I guess your patch is fairly complex but it should work
I should also add that although complex, it should have a
much smaller TSC delta window in which the wrong scaling
factor can get applied to it (I guess it is about as good
as you
On Saturday 08 December 2007 03:48, Nick Piggin wrote:
> On Friday 07 December 2007 22:17, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > > > not the jiffies
201 - 300 of 3926 matches
Mail list logo
