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
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
On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
> Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
>
> The test case below, taken from the LTP test code, prints -1 (as
> expected) on 2.6.22 and 0 on 2.6.23. It tries to remap an out-of-range
> page. Proposed patch f
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> On Tue, 27 Nov 2007 17:33:05 +0800
>
> "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote:
> > If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> > volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> > my 16-co
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
> On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
> > On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> > > sounds like a bad idea; volanomark (well, technically the jvm behind
> > > it) is abusin
On Friday 30 November 2007 13:51, Arjan van de Ven wrote:
> On Fri, 30 Nov 2007 13:46:22 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Todays kernel has a different behavior somewhat (and before people
> > > scream "regression"; sched_yield(
until the merge window, I'd like to
> set aside some time (from my other work items) to work on the memory
> controller, fix review comments and defects.
>
> In the past, we've received several useful comments from Rik Van Riel,
> Lee Schermerhorn, Peter Zijlstra, Hugh Dick
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Haven't we been asking JVMs to use futexes or posix locking for years
> > and years now? [...]
>
> i'm curious, with what JVM was it tested and where's t
On Monday 03 December 2007 19:45, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > Haven't we been asking JVMs to use futex
On Monday 03 December 2007 20:57, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > as far as desktop apps such as firefox goes, the exact opposite is
> > > true. We had two choices basically: either a "more agressive" yield
> > > th
On Monday 03 December 2007 21:33, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > I was just talking about the default because I didn't know the
> > > > reason for the way it was set -- now that I do, we should talk
> > > > a
On Mon, Dec 03, 2007 at 06:01:40PM +0530, Supriya Kannery wrote:
> Nick Piggin wrote:
> >On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
> >
> >>Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
> >>
> >>The test case belo
On Tuesday 04 December 2007 09:33, Ingo Molnar wrote:
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> >> heh, thanks :) For which workload does it make the biggest difference
> >> for you? (and compared to what other scheduler you used before?
> >> 2.6.22?)
> >
> > ..
> >
> > Heh.. I'm just a very unsop
On Monday 03 December 2007 22:37, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > given how poorly sched_yield() is/was defined the only "compatible"
> > > solution would be to go back to the old yield code.
> >
> > Wh
On Tuesday 04 December 2007 11:30, David Schwartz wrote:
> Perhaps it might be possible to scan for the task at the same static
> priority level that is ready-to-run but last in line among other
> ready-to-run tasks and put it after that task?
Nice level versus posix static priority level debate
ze (because it is no longer part of the
ramdisk code).
- Boot / load time flexible ramdisk size, which could easily be extended
to a per-ramdisk runtime changeable size (eg. with an ioctl).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
MAINTAINERS|5
drivers/block/
On Mon, Dec 03, 2007 at 10:29:03PM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2007 05:26:28 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy a
On Tue, Dec 04, 2007 at 08:01:31AM +0100, Nick Piggin wrote:
> Thanks for the review, I'll post an incremental patch in a sec.
Index: linux-2.6/drivers/block/brd.c
===
--- linux-2.6.orig/drivers/block/brd.c
+++ linux-2.6
On Tue, Dec 04, 2007 at 01:55:17AM -0600, Rob Landley wrote:
> On Monday 03 December 2007 22:26:28 Nick Piggin wrote:
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy and gets stored in RAM twice.
&g
On Tue, Dec 04, 2007 at 10:54:51AM +0100, Christian Borntraeger wrote:
> Am Dienstag, 4. Dezember 2007 schrieb Nick Piggin:
> [...]
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy and gets stored in RAM
On Tue, Dec 04, 2007 at 11:10:09AM +0100, Nick Piggin wrote:
> >
> > This is just an idea, I dont know if it is worth the trouble, but have you
> > though about implementing direct_access for brd? That would allow
> > execute-in-place (xip) on brd eliminating the extra co
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb->s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/f
On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > +*
> > +* Cannot support XIP and highmem, because our ->direct_access
> > +* routine for XIP must return
On Tue, Dec 04, 2007 at 12:35:49PM +0100, Nick Piggin wrote:
> On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
> > On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > + *
> > > + * Cannot support XIP a
On Tue, Dec 04, 2007 at 12:06:23PM +, Duane Griffin wrote:
> On 04/12/2007, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > + gfp_flags = GFP_NOIO | __GFP_ZERO;
> > +#ifndef CONFIG_BLK_DEV_XIP
> > + gfp_flags |= __GFP_HIGHMEM;
> > +#endif
>
On Wed, Dec 05, 2007 at 09:05:06AM +, Dave Airlie wrote:
>
> > Convert drm from nopage to fault.
> > Remove redundant vma range checks.
>
> Hi Nick,
>
> can you rebase against the -mm tree? or are you pushing this for before
> then? if so can you supply me a patch against -mm?
I'm not sure
the earliest deadline in the hope that we avoid a deadline
> expiry later on.
>
> Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
I think this seems reasonable. What's deadline doing in this case?
They should probably be kept in synch where possible...
Acked-by: Nick Piggin <[E
On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
> Am Wed, 05 Dec 2007 18:15:51 +1100
> schrieb [EMAIL PROTECTED]:
>
> > Convert uio from nopage to fault.
> >
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
>
On Wed, Dec 05, 2007 at 02:47:00PM -0800, Andrew Morton wrote:
> On Wed, 05 Dec 2007 18:16:04 +1100
> [EMAIL PROTECTED] wrote:
>
> > Nothing in the tree uses nopage any more. Remove support for it in the
> > core mm code and documentation (and a few stray references to it in
> > comments).
>
> I
On Wed, Dec 05, 2007 at 04:43:16PM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >Am I missing something here? I wonder how s390 works without this change?
> >
> >--
> >ext2 should not worry about checking sb->s_blocksize for XIP before the
> >sb's b
On Wed, Dec 05, 2007 at 09:06:50PM +1100, Aaron Carroll wrote:
> Two comments refer to deadlines applying to reads only. This is
> not the case.
>
> Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
> ---
> block/as-io
On Wed, Dec 05, 2007 at 11:25:00AM +0100, Hans-Jürgen Koch wrote:
> Am Wed, 5 Dec 2007 11:10:42 +0100
> schrieb Nick Piggin <[EMAIL PROTECTED]>:
>
> > On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
> > > Am Wed, 05 Dec 2007 18:15:51 +1100
he 1394 drivers and I'm too
> lazy to figure this out myself, so I ask: What would trip the .fault
> handler? Would be good if I could runtime-test it.
mmap()ing a device file for that driver, and accessing the memory.
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
On Wed, Dec 05, 2007 at 02:15:35PM +0100, Stefan Richter wrote:
> > [EMAIL PROTECTED] wrote:
> >> @@ -275,7 +270,7 @@ int dma_region_mmap(struct dma_region *d
> >>if (!dma->kvirt)
> >>return -EINVAL;
> >>
> >> - /* must be page-aligned */
> >> + /* must be page-aligned (XXX: com
On Wed, Dec 05, 2007 at 08:39:25AM -0800, Pete Zaitcev wrote:
> On Wed, 05 Dec 2007 18:15:59 +1100, [EMAIL PROTECTED] wrote:
>
> > Convert USB mon driver from nopage to fault.
>
> > if (offset >= rp->b_size)
> > - return NOPAGE_SIGBUS;
> > + return VM_FAULT_SIGBUS;
> >
On Thu, Dec 06, 2007 at 09:43:27AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >>Xip does only work, if both do match PAGE_SIZE because it
> >>does'nt support multiple calls to direct_access in the get_xip_page
> >>address space operation. Thus we
On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >After my patch, we can do XIP in a hardsect size < PAGE_SIZE block
> >device -- this seems to be a fine thing to do at least for the
> >ramdisk code. Would this situation be problema
On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
> On Mon, 19 Nov 2007, H. Peter Anvin wrote:
> > You're making the assumption here that NUMA = large number of CPUs. This
> > assumption is flat-out wrong.
>
> Well maybe. Usually one gets to NUMA because the hardware gets too big to
> be
On Mon, Nov 19, 2007 at 11:17:48AM -0800, Tim Pepper wrote:
> There is an unmatched parenthesis in the locking commentary of radix_tree.h
> which is trivially fixed by the patch below.
>
> Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
> Cc: Nick Piggin <[EMAIL PROTECTED]
On Tuesday 20 November 2007 13:02, Christoph Lameter wrote:
> On Mon, 19 Nov 2007, H. Peter Anvin wrote:
> > You're making the assumption here that NUMA = large number of CPUs. This
> > assumption is flat-out wrong.
>
> Well maybe. Usually one gets to NUMA because the hardware gets too big to
> be
On Tuesday 20 November 2007 15:12, Mark Lord wrote:
> On 32-bit x86, we have CONFIG_IRQBALANCE available,
> but not on 64-bit x86. Why not?
>
> I ask, because this feature seems almost essential to obtaining
> reasonable latencies during heavy I/O with fast devices.
>
> My 32-bit Core2Duo MythTV b
On Tuesday 20 November 2007 11:59, Ian Kumlien wrote:
> Hi,
>
> I have had this before and sent a mail about it.
>
> It seems like the diskcache is still in use and is never shrunk. This
> happened with a odd load though, trackerd started indexing a bit late
> and the other workload which is a larg
On Tuesday 20 November 2007 15:37, Adrian Bunk wrote:
> On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote:
> > Agreed. When userspace has something to do with the way IRQs are
> > delivered, it's going to smell as bad as micro-kernels...
>
> The next step to a micro-kernel would then b
Don't know who maintains vt.c, but Antonino's name comes up regularly ;)
--
vt is missing a memory barrier to close the critical section. Use a real
spinlock for this.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/d
On Tuesday 20 November 2007 16:37, Arjan van de Ven wrote:
> On Tue, 20 Nov 2007 15:17:15 +1100
> > For that matter, I'd like to know why it has been decided that the
> > best place for IRQ balancing is in userspace. It should be in kernel
> > IMO, and it would probably allow better power saving,
On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
>
> sidenote: the way i combat these missing pieces of instrumentation in
> the scheduler is to ad
On Tuesday 20 November 2007 18:26, Nick Piggin wrote:
> On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
> >
> > sidenote:
On Tuesday 20 November 2007 20:09, Ian Kumlien wrote:
> On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:
> > It's also used up all your 2.5GB of swap. The output of your `free` shows
> > a fair bit of disk cache there, but it also shows a lot of swap free,
> > w
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
> On Tue, 20 Nov 2007 18:37:39 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > actually no. IRQ balancing is not a "fast" decision; every time
> > > you
> >
> > I di
On Wednesday 21 November 2007 06:07, Arjan van de Ven wrote:
> On Wed, 21 Nov 2007 02:43:46 +1100
> > Of course it is, if you want to effectively use your resources.
> > Imagine if the task balancer only polled once every 10s.
>
> but unlike the task balancer, moving an irq is really expensive.
>
On Saturday 24 November 2007 00:09, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Ahh, hate to get off topic, but let's not perpetuate this myth. It
> > wasn't Con, or CFS, or anything that showed fairness is some great new
> > idea. Actu
tag lookup API as well...
> Furthermore, the existing radix_tree_gang_lookup() can use this same
> function if we define a RADIX_TREE_MAX_INDEX value so the search is not
> limited by the last_index.
Nit: should just define it to be ULONG_MAX.
>
> Signed-off-by: Dave Chinner <[EMA
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 Monday 14 January 2008 22:30, Andi Kleen wrote:
> In general there are more scaling problems like this (e.g. it also doesn't
> make sense to scale kernel threads for each CPU thread for example).
I think in a lot of ways, per-CPU kernel threads scale OK. At least
they should mostly be dynamic,
On Mon, Jan 14, 2008 at 10:14:46AM +0100, Jes Sorensen wrote:
> Nick Piggin wrote:
> >On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
> >>Nick,
> >>
> >>Is this supposed to apply to the latest Linus tree? I applied it here
> >>and the
On Thursday 17 January 2008 06:58, Dave Kleikamp wrote:
> On Wed, 2007-12-12 at 16:40 +1100, Nick Piggin wrote:
> > On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
> > > On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
> > > > Anyway, I am hoping that
On Friday 18 January 2008 10:41, Rusty Russell wrote:
> vfs_init_caches_early() does nothing on IA-64 and x86-64 (unless you
> turn off CONFIG_NUMA): hashdist is set by default on these platforms.
>
> Maybe some obscure feature which requires VFS to be set up v. early
> (hence is broken in this con
On Friday 18 January 2008 00:24, Peter Zijlstra wrote:
> [ At the very least CC'ing the scheduler maintainer would be
> helpful :-) ]
>
> On Wed, 2008-01-16 at 16:29 -0800, stephane eranian wrote:
> > Hello,
> >
> > As suggested by people on this list, I have changed perfmon2 to use
> > the high re
On Friday 18 January 2008 17:33, stephane eranian wrote:
> Nick,
> > It is arch specific. If an architecture wants interrupts on during
> > context switch, or runqueue unlocked, then they set it (btw
> > INTERRUPTS_ON_CTXSW also implies UNLOCKED_CTXSW).
>
> Yes , I noticed that. I am only interest
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.
Anywa
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
===
--- linux-2.6.orig/block/
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 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 w
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 c
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 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 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 off
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_tr
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 add
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. Dep
h were
> 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 P
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_writepag
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 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 pat
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 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
On Thursday 24 January 2008 02:48, Jan Kara wrote:
> On Thu 24-01-08 02:05:16, Nick Piggin wrote:
> > On Thursday 24 January 2008 00:30, Jan Kara wrote:
> > > On Wed 23-01-08 12:00:02, Nick Piggin wrote:
> > > > On Wednesday 23 January 2008 04:10,
On Friday 25 January 2008 19:15, Jan Beulich wrote:
> Actually, another thought: permitting (and handling) spurious faults for
> kernel mappings conflicts with NMI handling, i.e. great care would be
> needed to ensure the NMI path cannot touch any such mapping. So
> even the present Xen/Linux Dom0
On Saturday 26 January 2008 02:03, Asbjørn Sannes wrote:
> Asbjørn Sannes wrote:
> > Nick Piggin wrote:
> >> On Friday 25 January 2008 22:32, Asbjorn Sannes wrote:
> >>> Hi,
> >>>
> >>> I am experiencing unpredictable results with the following
On Friday 25 January 2008 22:32, Asbjorn Sannes wrote:
> Hi,
>
> I am experiencing unpredictable results with the following test
> without other processes running (exception is udev, I believe):
> cd /usr/src/test
> tar -jxf ../linux-2.6.22.12
> cp ../working-config linux-2.6.22.12/.config
> cd lin
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > &
On Sunday 27 January 2008 17:03, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <[EMAIL PROTECTED]>
> > wrote:
> >
> > - if (!page->mapping)
> > + if (!page->mapping) {
> > + if (!PageAnon(page) && PagePrivate(page))
> > + try_to_release_page(
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > &
On Sunday 27 January 2008 01:27, Pascal Terjan wrote:
> Nick Piggin yahoo.com.au> writes:
> > On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> > > I just succeeded to reproduce the problem with this patch. Does this
> > > smell like an XFS problem?
>
but the work is done so I guess I should send it along.
The minix filesystem uses bkl to protect access to metadata. Switch
to a per-superblock mutex.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/minix/bitmap.c
=
On Fri, 2005-03-11 at 20:27 +0100, Christian Schmid wrote:
> Ben Greear wrote:
> >
> > For what it's worth, I was running dual-xeon systems with HT turned on.
> >
> > But, I have a single process, single-threaded application, so there is
> > not much
> > scheduling to be done. If you have a lar
On Sat, 2005-03-12 at 23:20 +, Hugh Dickins wrote:
> Since cond_resched_lock's spin_lock clears break_lock, no need to clear it
> itself; and use need_lockbreak there too, preferring optimizer to #ifdefs.
>
FWIW, this patch solves the problems I had in mind (and so should
solve our copy_page
On Mon, 2005-03-14 at 05:53 +0100, Christian Schmid wrote:
> > The other thing that worries me is your need for lower_zone_protection.
> > I think this may be due to unbalanced highmem vs lowmem reclaim. It
> > would be interesting to know if those patches I sent you improve this.
> > They certain
Ingo Molnar wrote:
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
@@ -187,6 +187,8 @@ void __lockfunc _##op##_lock(locktype##_
cpu_relax();\
preempt_disable(); \
}
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
while writing the ->break_lock feature i intentionally avoided
overhead in the spinlock fastpath. A better solution for the bug you
noticed is to clear the break_lock flag in places that use
need_lock_break() explicitly.
What h
Arjan van de Ven wrote:
Yes that's the tradeoff. I just feel that the former may be better,
especially because the latter can be timing dependant (so you may get
things randomly "happening"), and the former is apparently very low
overhead compared with the cost of taking the lock. Any numbers,
anyo
Ingo Molnar wrote:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
as I said, since the cacheline just got dirtied, the write is just
half a cycle which is so much in the noise that it really doesn't
matter.
ok - the patch below is a small modification of Hugh's so that we clear
->break_lock uncond
Matt Mackall wrote:
+ for (;;) {
while (1)
I always thought for (;;) was preferred. Or at least acceptable?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.h
On Tue, 2005-03-15 at 20:12 -0800, Christoph Lameter wrote:
> This patch removes the zone padding hack and establishes definitions
> in include/linux/cache.h to define the padding within struct zone.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> Signed-off-by: Shai Fultheim <[EMAIL PR
Matthew Dobson wrote:
While looking at some bugs related to OOM handling in 2.6, Martin Bligh
and I noticed some order 0 page allocation failures from kswapd:
kswapd0: page allocation failure. order:0, mode:0x50
[] __alloc_pages+0x288/0x295
[] __get_free_pages+0x18/0x24
[] kmem_getpages+0x15/0
Ian Pratt wrote:
Folks,
When we upgraded arch xen/x86 to kernel 2.6.11, we noticed a slowdown
on a number of micro-benchmarks. In order to investigate, I built
native (non Xen) i686 uniprocessor kernels for 2.6.10 and 2.6.11 with
the same configuration and ran lmbench-3.0-a3 on them. The test
mac
Kurt Garloff wrote:
Hi Nick,
Hi Kurt!
On Thu, Mar 17, 2005 at 11:37:24PM +1100, Nick Piggin wrote:
Ian Pratt wrote:
fork: 166 -> 235 (40% slowdown)
exec: 857 -> 1003 (17% slowdown)
I'm guessing this is down to the 4 level pagetables. This is rather a
surprise as I thought the com
Matthew Dobson wrote:
Agreed. It seems unlikely, but not entirely impossible. All it would
take is one sloppily coded driver, right? How about this patch instead?
Sure that would be fine with me. It kind of makes the logic
explicit, as Martin said.
Nick
-
To unsubscribe from this list: send th
viking wrote:
Okay - so I see I'm not the only one to see significant slowdowns in 2.6.11.x
compared to 2.6.10 - guess I'll have to wait until the 4-level table thing
sorts itself out...
/me removes foot out of gob.
The 4-level page tables slowdowns don't explain the problems you
are seeing. 2.6.12
On Mon, 2005-03-21 at 15:02 -0800, David S. Miller wrote:
> Anyways, there's the full analysis, what do you make
> of this Hugh? :-)
Impressive, and my name isn't even Hugh.
Question, Dave: flush_tlb_pgtables after Hugh's patch is also
possibly not being called with enough range to cover all pag
401 - 500 of 1974 matches
Mail list logo
