On Wed, 04 Apr 2007 22:37:29 PDT, William Lee Irwin III said:
> The actual phenomenon of concern here is dense matrix code with sparse
> matrix inputs. The matrices will typically not be vast but may span 1MB
> or so of RAM (1024x1024 is 1M*sizeof(double), and various dense matrix
> algorithms tar
On Wed, Apr 04, 2007 at 05:27:31PM -0700, Linus Torvalds wrote:
>> Good point. In fact, it doesn't need to be a malloc() - I remember people
>> doing this with Fortran programs and just having an absolutely incredibly
>> big BSS (with traditional Fortran, dymic memory allocations are just not
>>
On Wed, Apr 04, 2007 at 01:11:11PM -0700, David S. Miller wrote:
> If we're going to consider this seriously, there is a case I know of.
> Look at flush_dcache_page()'s test for ZERO_PAGE() on sparc64, there
> is an instructive comment:
>
> /* Do not bother with the expensive D-cache flush i
On Wed, Apr 04, 2007 at 08:35:30AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 4 Apr 2007, Nick Piggin wrote:
> >
> > Shall I do a more complete patchset and ask Andrew to give it a
> > run in -mm?
>
> Do this trivial one first. See how it fares.
OK.
> Although I don't know how much -mm will d
On Wed, Apr 04, 2007 at 05:27:31PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 4 Apr 2007, [EMAIL PROTECTED] wrote:
> >
> > I'd not be surprised if there's sparse-matrix code out there that wants to
> > malloc a *huge* array (like a 1025x1025 array of numbers) that then only
> > actually *writes*
On Wed, Apr 04, 2007 at 01:11:11PM -0700, David Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Wed, 4 Apr 2007 08:35:30 -0700 (PDT)
>
> > Anyway, I'm not against this, but I can see somebody actually *wanting*
> > the ZERO page in some cases. I've used the fact for TLB testing,
On Wed, 04 Apr 2007 17:27:31 PDT, Linus Torvalds said:
> Sure you do. If glibc used mmap() or brk(), it *knows* the new data is
> zero. So if you use calloc(), for example, it's entirely possible that
> a good libc wouldn't waste time zeroing it.
Right. However, the *user* code usually has no
On Wed, 4 Apr 2007, [EMAIL PROTECTED] wrote:
>
> I'd not be surprised if there's sparse-matrix code out there that wants to
> malloc a *huge* array (like a 1025x1025 array of numbers) that then only
> actually *writes* to several hundred locations, and relies on the fact that
> all the untouched
On Wed, 04 Apr 2007 08:35:30 PDT, Linus Torvalds said:
> Although I don't know how much -mm will do for it. There is certainly not
> going to be any correctness problems, afaik, just *performance* problems.
> Does anybody do any performance testing on -mm?
I have to admit I don't do anything mo
On Wed, 04 Apr 2007 17:48:39 +0200, Andrea Arcangeli said:
> Ok, those cases wanting the same zero page, could be fairly easily
> converted to an mmap over /dev/zero (without having to run 4k large
> mmap syscalls or nonlinear).
"D'oh!" -- H. Simpson.
Ignore my previous note. :)
pgpDXeDCPhdZQ.
On Wed, 04 Apr 2007 13:11:11 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> As I understand the patch being considered to remove ZERO_PAGE(), this
> kind of core dump will cause a lot of pages to be allocated, probably
> eating up a lot of system time as well as memory.
Point.
Also, what
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 08:35:30 -0700 (PDT)
> Anyway, I'm not against this, but I can see somebody actually *wanting*
> the ZERO page in some cases. I've used the fact for TLB testing, for
> example, by just doing a big malloc(), and knowing that the kerne
On Wed, 4 Apr 2007 08:35:30 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> Does anybody do any performance testing on -mm?
http://test.kernel.org/perf/index.html has pretty graphs of lots of kernel
versions
for a few benchmarks. I'm not aware of any other organised effort along those
On Wed, 4 Apr 2007, Eric Dumazet wrote:
>
> But results on an Intel Pentium-M are interesting, in particular 2) & 3)
>
> If a page is first allocated as page_zero then cow to a full rw page, this is
> more expensive.
> (2660 cycles instead of 2300)
Yes, you have an extra TLB flush there at a
Hi Dan,
On Wed, Apr 04, 2007 at 07:15:15PM +0300, Dan Aloni wrote:
> The main difference is that disk-backed swap can create I/O pressure which
> would slow down the swap-outs that are not of zeroed pages (and other I/Os
> on that disk for that matter). For purely-RAM virtual memory the latency
>
On Wed, 4 Apr 2007 08:35:30 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Anyway, I'm not against this, but I can see somebody actually *wanting*
> the ZERO page in some cases. I've used the fact for TLB testing, for
> example, by just doing a big malloc(), and knowing that the kernel
On Wed, Apr 04, 2007 at 05:10:37PM +0100, Hugh Dickins wrote:
> file will be written to later on), and MAP_PRIVATE mmap of /dev/zero
Obviously I meant MAP_PRIVATE of /dev/zero, since it's the only one
backed by the zero page.
> uses the zeromap stuff which we were hoping to eliminate too
> (thoug
On Wed, Apr 04, 2007 at 09:09:28AM -0700, Linus Torvalds wrote:
> You're missing the point. What if it's something like oracle that has been
> tuned for Linux using this? Or even an open-source app that is just used
> by big places and they see performace problems but it's not obvious *why*.
>
>
On Wed, 4 Apr 2007, Hugh Dickins wrote:
> On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
> > On Wed, Apr 04, 2007 at 04:03:15PM +0100, Hugh Dickins wrote:
> > > Maybe Nick will decide to not to mark the readfaults as dirty.
> >
> > I don't like to mark the pte readonly and clean,
>
> Nor I: I mea
On Wed, Apr 04, 2007 at 05:27:17PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 05:44:21PM +0300, Dan Aloni wrote:
> > To refine that example, you could replace the file with a large anonymous
> > memory pool and a lot of swap space committed to it. In that case - with
> > no ZERO_PAG
On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
>
> Ok, those cases wanting the same zero page, could be fairly easily
> converted to an mmap over /dev/zero (without having to run 4k large
> mmap syscalls or nonlinear).
You're missing the point. What if it's something like oracle that has been
tun
On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 08:35:30AM -0700, Linus Torvalds wrote:
> > Anyway, I'm not against this, but I can see somebody actually *wanting*
> > the ZERO page in some cases. I've used the fact for TLB testing, for
> > example, by just doing a big mallo
On Wed, Apr 04, 2007 at 04:41:46PM +0100, Hugh Dickins wrote:
> Nor I: I meant that anonymous readfault should
> (perhaps) mark the pte writable but clean.
Sorry I assumed when you said clean you implied readonly... Though
we'd need to differentiate the archs where the dirty bit is not set by
the
On Wed, Apr 04, 2007 at 08:35:30AM -0700, Linus Torvalds wrote:
> Anyway, I'm not against this, but I can see somebody actually *wanting*
> the ZERO page in some cases. I've used the fact for TLB testing, for
> example, by just doing a big malloc(), and knowing that the kernel will
> re-use the
On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 04:03:15PM +0100, Hugh Dickins wrote:
> > Maybe Nick will decide to not to mark the readfaults as dirty.
>
> I don't like to mark the pte readonly and clean,
Nor I: I meant that anonymous readfault should
(perhaps) mark the pte
On Wed, 4 Apr 2007, Nick Piggin wrote:
>
> Shall I do a more complete patchset and ask Andrew to give it a
> run in -mm?
Do this trivial one first. See how it fares.
Although I don't know how much -mm will do for it. There is certainly not
going to be any correctness problems, afaik, just *pe
On Wed, Apr 04, 2007 at 04:03:15PM +0100, Hugh Dickins wrote:
> Maybe Nick will decide to not to mark the readfaults as dirty.
I don't like to mark the pte readonly and clean, we'd be still
optimizing for the current ZERO_PAGE users and even for those it would
generate a unnecessary page fault if
On Wed, Apr 04, 2007 at 05:44:21PM +0300, Dan Aloni wrote:
> To refine that example, you could replace the file with a large anonymous
> memory pool and a lot of swap space committed to it. In that case - with
> no ZERO_PAGE, would the kernel needlessly swap-out the zeroed pages?
Swapout or ram
On Wed, 4 Apr 2007, Dan Aloni wrote:
>
> To refine that example, you could replace the file with a large anonymous
> memory pool and a lot of swap space committed to it. In that case - with
> no ZERO_PAGE, would the kernel needlessly swap-out the zeroed pages?
> Perhaps it's an example too far-
On Wed, Apr 04, 2007 at 04:14:57PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 04:55:32PM +0300, Dan Aloni wrote:
> > How about applications that perform mmap() and R/W random-access on
> > large *sparse* files? (e.g. a scientific app that uses a large sparse
> > file as a big databa
On Wed, Apr 04, 2007 at 04:55:32PM +0300, Dan Aloni wrote:
> How about applications that perform mmap() and R/W random-access on
> large *sparse* files? (e.g. a scientific app that uses a large sparse
> file as a big database look-up table). As I see it, these apps would
> need to keep track of w
On Wed, Apr 04, 2007 at 02:27:01PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 12:24:07PM +0200, Nick Piggin wrote:
> > But for a potential mainline merge, maybe starting with a CONFIG
> > option is a good idea -- defaulting to off, and we could start by
> > turning it on just in -rc k
On Wed, Apr 04, 2007 at 02:32:03PM +0100, Hugh Dickins wrote:
> That's a little unfortunate, since we'd then have to lose the win from
> this change, that we issue a writable zeroed page (when VM_WRITE) in
> do_anonymous_page, even when it's a read fault, saving subsequent fault.
Hmm no, that win
On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 01:45:06PM +0100, Hugh Dickins wrote:
> > I'm confused. CONFIG_ZERO_PAGE off is where we'd like to end up: how
> > would turning CONFIG_ZERO_PAGE on in -rc kernels help us to get there?
>
> He most certainly meant on by default
On Wed, Apr 04, 2007 at 01:45:06PM +0100, Hugh Dickins wrote:
> I'm confused. CONFIG_ZERO_PAGE off is where we'd like to end up: how
> would turning CONFIG_ZERO_PAGE on in -rc kernels help us to get there?
He most certainly meant on by default.
I think if we do this, we also need a zeropage coun
On Wed, 4 Apr 2007, Nick Piggin wrote:
>
> No, you have a point, but if we have to ask people to recompile
> with CONFIG_ZERO_PAGE, then it isn't much harder to ask them to
> apply a patch first.
>
> But for a potential mainline merge, maybe starting with a CONFIG
> option is a good idea -- defa
On Wed, Apr 04, 2007 at 12:24:07PM +0200, Nick Piggin wrote:
> But for a potential mainline merge, maybe starting with a CONFIG
> option is a good idea -- defaulting to off, and we could start by
> turning it on just in -rc kernels for a few releases, to get a bit
> more confidence?
The only reaso
On Wed, Apr 04, 2007 at 10:45:39AM +0100, Hugh Dickins wrote:
> On Wed, 4 Apr 2007, Nick Piggin wrote:
> > On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
> > >
> > > Well it would make life easier if we got rid of ZERO_PAGE completely,
> > > which I definitely wouldn't complain about
On Wed, 4 Apr 2007, Nick Piggin wrote:
> On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
> >
> > Well it would make life easier if we got rid of ZERO_PAGE completely,
> > which I definitely wouldn't complain about ;)
Yes, I love this approach too.
>
> So, what bad things (apart fro
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
>
> Well it would make life easier if we got rid of ZERO_PAGE completely,
> which I definitely wouldn't complain about ;)
So, what bad things (apart from my bugs in untested code) happen
if we do this? We can actually go further, and pr
40 matches
Mail list logo
