On Thu, Nov 22, 2007 at 10:51:15AM +1100, Bron Gondwana wrote:
> On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote:
> > If this patch makes a difference, please holler. I think it's the correct
> > thing to do, but I'm not going to actually commit it without somebody
> > saying that
On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote:
> On Thu, 15 Nov 2007, Bron Gondwana wrote:
> >
> > I guess we'll be doing the one-liner kernel mod and testing
> > that then.
>
> The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and
> in this particular case
On Thu, 15 Nov 2007 13:47:54 -0800 (PST) Linus Torvalds wrote:
>
>But quite frankly, I refuse to even care about anything past that. If
>you have 12G (or heaven forbid, even more) in your machine, and you
>can't be bothered to just upgrade to a 64-bit CPU, then quite frankly,
>*I* personally
On Thu, 15 Nov 2007 13:47:54 -0800 (PST) Linus Torvalds wrote:
But quite frankly, I refuse to even care about anything past that. If
you have 12G (or heaven forbid, even more) in your machine, and you
can't be bothered to just upgrade to a 64-bit CPU, then quite frankly,
*I* personally can't
On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote:
On Thu, 15 Nov 2007, Bron Gondwana wrote:
I guess we'll be doing the one-liner kernel mod and testing
that then.
The thing to look at is get_dirty_limits() in mm/page-writeback.c, and
in this particular case it's the
On Thu, Nov 22, 2007 at 10:51:15AM +1100, Bron Gondwana wrote:
On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote:
If this patch makes a difference, please holler. I think it's the correct
thing to do, but I'm not going to actually commit it without somebody
saying that it
On Thu, Nov 15, 2007 at 01:14:32PM -0800, Linus Torvalds wrote:
Sorry about not replying to this earlier. I actually got a weekend
away from the computer pretty much last weekend - took the kids
swimming, helped a friend clear dead wood from around her house
before the fire season. Shocking I
On Sun, Nov 18, 2007 at 04:13:18PM -0700, Daniel Phillips wrote:
> On Thursday 15 November 2007 14:24, Rob Mueller wrote:
> > > That's my personal opinion, and I realize that some of the
> > > commercial vendors may care about their insane customers'
> > > satisfaction, but I'm simply not
On Thursday 15 November 2007 14:24, Rob Mueller wrote:
> > That's my personal opinion, and I realize that some of the
> > commercial vendors may care about their insane customers'
> > satisfaction, but I'm simply not interested in insane users. If
> > they have that much RAM (and bought it a few
On Thursday 15 November 2007 14:24, Rob Mueller wrote:
That's my personal opinion, and I realize that some of the
commercial vendors may care about their insane customers'
satisfaction, but I'm simply not interested in insane users. If
they have that much RAM (and bought it a few years ago
On Sun, Nov 18, 2007 at 04:13:18PM -0700, Daniel Phillips wrote:
On Thursday 15 November 2007 14:24, Rob Mueller wrote:
That's my personal opinion, and I realize that some of the
commercial vendors may care about their insane customers'
satisfaction, but I'm simply not interested in
On Thu, Nov 15, 2007 at 01:14:32PM -0800, Linus Torvalds wrote:
Sorry about not replying to this earlier. I actually got a weekend
away from the computer pretty much last weekend - took the kids
swimming, helped a friend clear dead wood from around her house
before the fire season. Shocking I
> So the _only_ explanation today for 12GB on a 32-bit machine is
> (a) insanity
> or
> (b) being so lazy as to not bother to upgrade
> and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm
> lazy too, and I can't give a rats *ss about those problems".
12GB-16GB worked
That's my personal opinion, and I realize that some of the commercial
vendors may care about their insane customers' satisfaction, but I'm
simply not interested in insane users. If they have that much RAM (and
bought it a few years ago when a 64-bit CPU wasn't an option), they can't
be poor.
On Thu, 15 Nov 2007, Chris Friesen wrote:
>
> We've got some 32-bit 8GB boxes for which both of these would hold true.
Still not enough of a reason for me to care.
Remember - I'm the guy who refused to merge RH's 4G:4G patches because I
thought they were an unsupportable nightmare.
I care a
Linus Torvalds wrote:
So the _only_ explanation today for 12GB on a 32-bit machine is
(a) insanity
or
(b) being so lazy as to not bother to upgrade
and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm
lazy too, and I can't give a rats *ss about those problems".
How
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
>
> But this problem is already an issue, Anton recently had a case where a
> 12GB highmem box locked up due to NTFS running out of lowmem - or
> something like that.
Yeah. I always considered HIGHMEM to just be unusable. It's ok for
extending to
On Thu, 2007-11-15 at 13:14 -0800, Linus Torvalds wrote:
>
> On Thu, 15 Nov 2007, Linus Torvalds wrote:
> >
> > Unacceptable. We used to do exactly what your patch does, and it got fixed
> > once. We're not introducing that fundamentally broken concept again.
>
> Examples of non-broken
On Thu, 15 Nov 2007, Linus Torvalds wrote:
>
> The problem with HIGHMEM is that it causes various metadata (dentries,
> inodes, page struct tables etc) to eat up memory "prime real estate" under
> the same kind of conditions that also dirty a lot of memory. So the reason
> we disallow
On Thu, 2007-11-15 at 21:59 +0100, Peter Zijlstra wrote:
> On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote:
> >
> > On Thu, 15 Nov 2007, Peter Zijlstra wrote:
> > >
> > > Something like this ought to do I guess. Although my
> > > mapping_is_buffercache() is the ugliest thing. I'm sure
On Thu, 15 Nov 2007, Linus Torvalds wrote:
>
> Unacceptable. We used to do exactly what your patch does, and it got fixed
> once. We're not introducing that fundamentally broken concept again.
Examples of non-broken solutions:
(a) always use lowmem sizes (what we do now)
(b) always use
On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote:
>
> On Thu, 15 Nov 2007, Peter Zijlstra wrote:
> >
> > Something like this ought to do I guess. Although my
> > mapping_is_buffercache() is the ugliest thing. I'm sure that can be done
> > better.
>
> No, this absolutely sucks.
Agreed,
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
>
> Something like this ought to do I guess. Although my
> mapping_is_buffercache() is the ugliest thing. I'm sure that can be done
> better.
No, this absolutely sucks.
Why?
It's totally unacceptable to have per-mapping notions of how much memory
On Thu, 2007-11-15 at 20:40 +0100, Peter Zijlstra wrote:
> As for the highmem part, that was due to buffer cache, and unfortunately
> that is still true. Although maybe we can do something smart with the
> per-bdi stuff.
Something like this ought to do I guess. Although my
On Thu, 2007-11-15 at 08:32 -0800, Linus Torvalds wrote:
>
> On Thu, 15 Nov 2007, Bron Gondwana wrote:
> >
> > I guess we'll be doing the one-liner kernel mod and testing
> > that then.
>
> The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and
> in this particular case it's
On Thu, 15 Nov 2007, Bron Gondwana wrote:
>
> I guess we'll be doing the one-liner kernel mod and testing
> that then.
The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and
in this particular case it's the
unsigned long available_memory =
On Thu, 15 Nov 2007, Bron Gondwana wrote:
I guess we'll be doing the one-liner kernel mod and testing
that then.
The thing to look at is get_dirty_limits() in mm/page-writeback.c, and
in this particular case it's the
unsigned long available_memory = determine_dirtyable_memory();
On Thu, 2007-11-15 at 08:32 -0800, Linus Torvalds wrote:
On Thu, 15 Nov 2007, Bron Gondwana wrote:
I guess we'll be doing the one-liner kernel mod and testing
that then.
The thing to look at is get_dirty_limits() in mm/page-writeback.c, and
in this particular case it's the
On Thu, 2007-11-15 at 20:40 +0100, Peter Zijlstra wrote:
As for the highmem part, that was due to buffer cache, and unfortunately
that is still true. Although maybe we can do something smart with the
per-bdi stuff.
Something like this ought to do I guess. Although my
mapping_is_buffercache()
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
Something like this ought to do I guess. Although my
mapping_is_buffercache() is the ugliest thing. I'm sure that can be done
better.
No, this absolutely sucks.
Why?
It's totally unacceptable to have per-mapping notions of how much memory
we
On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote:
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
Something like this ought to do I guess. Although my
mapping_is_buffercache() is the ugliest thing. I'm sure that can be done
better.
No, this absolutely sucks.
Agreed, I was just
On Thu, 2007-11-15 at 21:59 +0100, Peter Zijlstra wrote:
On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote:
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
Something like this ought to do I guess. Although my
mapping_is_buffercache() is the ugliest thing. I'm sure that can be
On Thu, 15 Nov 2007, Linus Torvalds wrote:
Unacceptable. We used to do exactly what your patch does, and it got fixed
once. We're not introducing that fundamentally broken concept again.
Examples of non-broken solutions:
(a) always use lowmem sizes (what we do now)
(b) always use total
On Thu, 15 Nov 2007, Linus Torvalds wrote:
The problem with HIGHMEM is that it causes various metadata (dentries,
inodes, page struct tables etc) to eat up memory prime real estate under
the same kind of conditions that also dirty a lot of memory. So the reason
we disallow HIGHMEM from
On Thu, 2007-11-15 at 13:14 -0800, Linus Torvalds wrote:
On Thu, 15 Nov 2007, Linus Torvalds wrote:
Unacceptable. We used to do exactly what your patch does, and it got fixed
once. We're not introducing that fundamentally broken concept again.
Examples of non-broken solutions:
(a)
On Thu, 15 Nov 2007, Peter Zijlstra wrote:
But this problem is already an issue, Anton recently had a case where a
12GB highmem box locked up due to NTFS running out of lowmem - or
something like that.
Yeah. I always considered HIGHMEM to just be unusable. It's ok for
extending to 2-4GB
Linus Torvalds wrote:
So the _only_ explanation today for 12GB on a 32-bit machine is
(a) insanity
or
(b) being so lazy as to not bother to upgrade
and in either case, my personal reaction is I'm *not* crazy, and yes, I'm
lazy too, and I can't give a rats *ss about those problems.
How
On Thu, 15 Nov 2007, Chris Friesen wrote:
We've got some 32-bit 8GB boxes for which both of these would hold true.
Still not enough of a reason for me to care.
Remember - I'm the guy who refused to merge RH's 4G:4G patches because I
thought they were an unsupportable nightmare.
I care a
That's my personal opinion, and I realize that some of the commercial
vendors may care about their insane customers' satisfaction, but I'm
simply not interested in insane users. If they have that much RAM (and
bought it a few years ago when a 64-bit CPU wasn't an option), they can't
be poor.
So the _only_ explanation today for 12GB on a 32-bit machine is
(a) insanity
or
(b) being so lazy as to not bother to upgrade
and in either case, my personal reaction is I'm *not* crazy, and yes, I'm
lazy too, and I can't give a rats *ss about those problems.
12GB-16GB worked well
40 matches
Mail list logo
