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 Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > > Ingo Molnar wrote:
> > > >
> > > >for example git-bisect was godsent. I remember that
> > > >years ago bisection of a bug was a
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 Sat, Nov 17, 2007 at 01:20:10PM +0100, Adrian Bunk wrote:
> > But a bisect takes around 7 compiles.
> >...
>
> I don't understand that number.
>
> The common case are regressions in -rc1, and a bisection of
> at about 7000 commits takes around 13 compiles.
Worst case it would take 13. In
On 18-11-07 15:35, James Bottomley wrote:
clean-cg? But failure to run "git repack -a -d" every once in a while?
Actually, the best command is
git gc
which does a repack (into a single pack file rather than an incremenal),
and then removes all the objects now in the pack. If, like me, you
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > >
> > >for example git-bisect was godsent. I remember that
> > >years ago bisection of a bug was a very laborous task
> > >so that it was only used as a final, last-ditch
> >
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote:
> On 18-11-07 13:44, Pavel Machek wrote:
>
> > On Tue 2007-11-13 12:50:08, Mark Lord wrote:
>
> >> It's a 540MByte download over a slow link for everyone
> >> else.
> >
> > Hmmm, clean-cg is 7.7G on my machine, and yes I tried
> >
On 18-11-07 13:44, Pavel Machek wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone
else.
Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am I doing wrong?
clean-cg? But failure to run "git repack -a -d"
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> Ingo Molnar wrote:
> >
> >for example git-bisect was godsent. I remember that
> >years ago bisection of a bug was a very laborous task
> >so that it was only used as a final, last-ditch
> >approach for really nasty bugs. Today we can
>
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
Ingo Molnar wrote:
for example git-bisect was godsent. I remember that
years ago bisection of a bug was a very laborous task
so that it was only used as a final, last-ditch
approach for really nasty bugs. Today we can
autonomouly bisect
On 18-11-07 13:44, Pavel Machek wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone
else.
Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am I doing wrong?
clean-cg? But failure to run git repack -a -d
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote:
On 18-11-07 13:44, Pavel Machek wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone
else.
Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am
* Pavel Machek [EMAIL PROTECTED] wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
Ingo Molnar wrote:
for example git-bisect was godsent. I remember that
years ago bisection of a bug was a very laborous task
so that it was only used as a final, last-ditch
approach for really
On 18-11-07 15:35, James Bottomley wrote:
clean-cg? But failure to run git repack -a -d every once in a while?
Actually, the best command is
git gc
which does a repack (into a single pack file rather than an incremenal),
and then removes all the objects now in the pack. If, like me, you
On Sat, Nov 17, 2007 at 01:20:10PM +0100, Adrian Bunk wrote:
But a bisect takes around 7 compiles.
...
I don't understand that number.
The common case are regressions in -rc1, and a bisection of
at about 7000 commits takes around 13 compiles.
Worst case it would take 13. In practice
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
On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
Ingo Molnar wrote:
for example git-bisect was godsent. I remember that
years ago bisection of a bug was a very laborous task
so
On Fri, Nov 16, 2007 at 02:46:18PM -0500, Theodore Tso wrote:
> On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote:
> > Compared to getting useful suggestions from a mailing list, especially
> > before you've gotten anybody's attention? Hours or overnight isn't
> > particularly
On Fri, Nov 16, 2007 at 02:46:18PM -0500, Theodore Tso wrote:
On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote:
Compared to getting useful suggestions from a mailing list, especially
before you've gotten anybody's attention? Hours or overnight isn't
particularly long, and
Hi Dave,
* David Miller <[EMAIL PROTECTED]> [071114 02:09]:
>
> In fact, *poof*, there it is, [EMAIL PROTECTED] is there and
> available for anyone who wants to use it.
Can you please use your *poof* trick one more time to set up
[EMAIL PROTECTED]
We've (as in linux-omap community) would
On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote:
> Compared to getting useful suggestions from a mailing list, especially
> before you've gotten anybody's attention? Hours or overnight isn't
> particularly long, and doesn't take up much of your time if you've got a
> working
On Fri, 16 Nov 2007, Romano Giannetti wrote:
>
> (Cc: trimmed a bit).
>
> On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
> > On Thu, 15 Nov 2007, Theodore Tso wrote:
> [...]
> > > A full kernel build with everything selected can take good 30 minutes or
> > > more, and that's on a
(Cc: trimmed a bit).
On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
> On Thu, 15 Nov 2007, Theodore Tso wrote:
[...]
> > A full kernel build with everything selected can take good 30 minutes or
> > more, and that's on a fast dual-core machine with 4gigs of memory and
> > 7200rpm
(Cc: trimmed a bit).
On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
On Thu, 15 Nov 2007, Theodore Tso wrote:
[...]
A full kernel build with everything selected can take good 30 minutes or
more, and that's on a fast dual-core machine with 4gigs of memory and
7200rpm disk
On Fri, 16 Nov 2007, Romano Giannetti wrote:
(Cc: trimmed a bit).
On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote:
On Thu, 15 Nov 2007, Theodore Tso wrote:
[...]
A full kernel build with everything selected can take good 30 minutes or
more, and that's on a fast dual-core
On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote:
Compared to getting useful suggestions from a mailing list, especially
before you've gotten anybody's attention? Hours or overnight isn't
particularly long, and doesn't take up much of your time if you've got a
working kernel
Hi Dave,
* David Miller [EMAIL PROTECTED] [071114 02:09]:
snip
In fact, *poof*, there it is, [EMAIL PROTECTED] is there and
available for anyone who wants to use it.
Can you please use your *poof* trick one more time to set up
[EMAIL PROTECTED]
We've (as in linux-omap community) would
> 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
On Thu, Nov 15, 2007 at 01:50:43PM +1100, Neil Brown wrote:
> Virtual Folders.
>
> I use VM mode in EMACS, but I believe some other mail readers have the
> same functionality.
> I have a virtual folder called "nfs" which shows me all mail in my
> inbox which has the string 'nfs' or 'lockd' in 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.
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 Tue, Nov 13, 2007 at 10:34:37PM +, Russell King wrote:
> On Tue, Nov 13, 2007 at 06:25:16PM +, Alan Cox wrote:
> > > Given the wide range of ARM platforms today, it is utterly idiotic to
> > > expect a single person to be able to provide responses for all ARM bugs.
> > > I for one wish
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, Theodore Tso wrote:
> On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
> > I don't see any reason that we couldn't have a tool accessible to Ubuntu
> > users that does a real "git bisect". Git is really good at being scripted
> > by fancy GUIs. It should be
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 Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
> I don't see any reason that we couldn't have a tool accessible to Ubuntu
> users that does a real "git bisect". Git is really good at being scripted
> by fancy GUIs. It should be easy enough to have a drop down with all of
> the
On 15-11-07 14:00, Jörn Engel wrote:
And even without mails being held hostage for weeks, every single
moderation mail is annoying. Like the one I'm sure to receive after
sending this out.
Certainly. Upto this thread I wasn't actually aware the list was doing that.
While it might be
At Thu, 15 Nov 2007 14:17:27 +0100,
Olivier Galibert wrote:
>
> On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
> > Totally unrelated indeed so why are spouting crap? If the kohab list has a
> > problem take it up with them but keep ALSA out of it. alsa-devel has only
> > ever
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
> Totally unrelated indeed so why are spouting crap? If the kohab list has a
> problem take it up with them but keep ALSA out of it. alsa-devel has only
> ever moderated out spam -- nothing else.
That is incorrect. Hopefully it is
On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote:
>
> Can you please just shelve this crap? You have a way of knowing that "ALSA
> will accept you" and that is knowing or assuming that the ALSA project
> doesn't consist of drooling retards.
Well, my experience with moderation has
On 15-11-07 13:02, Bron Gondwana wrote:
I get the same information from both project websites: "moderated for
non-members, public archives" - no way of knowing that ALSA will accept
me informing them of something they would be interested without
committing to reading or bit-bucketing their
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
> On 15-11-07 05:16, Bron Gondwana wrote:
>
>> Totally unrelated - I sent something to the kolab mailing list a couple
>
> [ ... ]
>
>> I'm sure if I had something that I considered worth informing the ALSA
>> project of, I'd be wary of
On Wed, Nov 14, 2007 at 09:53:38PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 14 Nov 2007, Linus Torvalds wrote:
> >
> > So even at 100% dirty limits, it won't let you dirty more than 1GB on the
> > default 32-bit setup.
>
> Side note: all of these are obviously still just heuristics. If you
On Wed, Nov 14, 2007 at 09:53:38PM -0800, Linus Torvalds wrote:
On Wed, 14 Nov 2007, Linus Torvalds wrote:
So even at 100% dirty limits, it won't let you dirty more than 1GB on the
default 32-bit setup.
Side note: all of these are obviously still just heuristics. If you really
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
On 15-11-07 05:16, Bron Gondwana wrote:
Totally unrelated - I sent something to the kolab mailing list a couple
[ ... ]
I'm sure if I had something that I considered worth informing the ALSA
project of, I'd be wary of spending
On 15-11-07 13:02, Bron Gondwana wrote:
I get the same information from both project websites: moderated for
non-members, public archives - no way of knowing that ALSA will accept
me informing them of something they would be interested without
committing to reading or bit-bucketing their list.
On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote:
Can you please just shelve this crap? You have a way of knowing that ALSA
will accept you and that is knowing or assuming that the ALSA project
doesn't consist of drooling retards.
Well, my experience with moderation has been that
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
Totally unrelated indeed so why are spouting crap? If the kohab list has a
problem take it up with them but keep ALSA out of it. alsa-devel has only
ever moderated out spam -- nothing else.
That is incorrect. Hopefully it is the
At Thu, 15 Nov 2007 14:17:27 +0100,
Olivier Galibert wrote:
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote:
Totally unrelated indeed so why are spouting crap? If the kohab list has a
problem take it up with them but keep ALSA out of it. alsa-devel has only
ever moderated
On 15-11-07 14:00, Jörn Engel wrote:
And even without mails being held hostage for weeks, every single
moderation mail is annoying. Like the one I'm sure to receive after
sending this out.
Certainly. Upto this thread I wasn't actually aware the list was doing that.
While it might be
On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
I don't see any reason that we couldn't have a tool accessible to Ubuntu
users that does a real git bisect. Git is really good at being scripted
by fancy GUIs. It should be easy enough to have a drop down with all of
the
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, 15 Nov 2007, Theodore Tso wrote:
On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
I don't see any reason that we couldn't have a tool accessible to Ubuntu
users that does a real git bisect. Git is really good at being scripted
by fancy GUIs. It should be easy
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 Tue, Nov 13, 2007 at 10:34:37PM +, Russell King wrote:
On Tue, Nov 13, 2007 at 06:25:16PM +, Alan Cox wrote:
Given the wide range of ARM platforms today, it is utterly idiotic to
expect a single person to be able to provide responses for all ARM bugs.
I for one wish I'd never
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.
On Thu, Nov 15, 2007 at 01:50:43PM +1100, Neil Brown wrote:
Virtual Folders.
I use VM mode in EMACS, but I believe some other mail readers have the
same functionality.
I have a virtual folder called nfs which shows me all mail in my
inbox which has the string 'nfs' or 'lockd' in a To, Cc,
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
On 15-11-07 05:16, Bron Gondwana wrote:
Totally unrelated - I sent something to the kolab mailing list a couple
[ ... ]
I'm sure if I had something that I considered worth informing the ALSA
project of, I'd be wary of spending the same effort writing a good post
knowing it may be dropped in
On Wed, 14 Nov 2007, Linus Torvalds wrote:
>
> So even at 100% dirty limits, it won't let you dirty more than 1GB on the
> default 32-bit setup.
Side note: all of these are obviously still just heuristics. If you really
*do* run on a 32-bit kernel, and you want to have the pain, I'm sure you
On Thu, 15 Nov 2007, Bron Gondwana wrote:
>
> So we've already been running those settings for a while. They didn't
> help.
Ok, so something else is up. If the mmap file is 2G, and you have 6G of
RAM, you shouldn't be hitting the dirty limits with those setups.
Of course, it may still be
On Wed, Nov 14, 2007 at 08:24:53PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 15 Nov 2007, Bron Gondwana wrote:
> >
> > And congratulations to him for that. We almost entirely dropped 2.6.16,
> > but there's a regression some time since then that makes large MMAPed
> > files a major pain
On Tue, Nov 13, 2007 at 10:56:01PM +0100, Christian Kujau wrote:
> On Tue, 13 Nov 2007, Andrew Morton wrote:
>> There are a number of process things we _could_ do. Like
>> - have bugfix-only kernel releases
>
> Adrian Bunk does (did?) this with 2.6.16.x, although it always seemed to me
> like an
On Thu, 15 Nov 2007, Bron Gondwana wrote:
>
> And congratulations to him for that. We almost entirely dropped 2.6.16,
> but there's a regression some time since then that makes large MMAPed
> files a major pain (specifically the dcc database clean takes about 5
> minutes on 2.6.16 and about 12
On Wed, Nov 14, 2007 at 12:46:24PM +0100, Rene Herman wrote:
> On 14-11-07 11:07, David Miller wrote:
>
> Added Jaroslav and Takashi to the already extensive CC
>
>> From: Russell King <[EMAIL PROTECTED]>
>
>>> So, when are you creating a replacement alsa-devel mailing list on
>>> vger?
On Tuesday November 13, [EMAIL PROTECTED] wrote:
> On Tuesday 13 November 2007 07:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > ..
> >
> > > This is all QA-101 that _cannot be argued against on a rational basis_,
> > > it's just that these sorts of things have been largely ignored for
> > >
On Wednesday November 14, [EMAIL PROTECTED] wrote:
> On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote:
> > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote:
> > > so please stop this "too busy and too noisy" nonsense already. It was
> > > nonsense 10 years ago and it's nonsense
On Tue, 13 Nov 2007, Theodore Tso wrote:
> There are two parts to this. One is a Ubuntu development kernel which
> we can give to large numbers of people to expand our testing pool.
> But if we don't do a better job of responding to bug reports that
> would be generated by expanded testing this
On Thu, 15 Nov 2007, Heikki Orsila wrote:
>
> See
> http://bugzilla.kernel.org/show_bug.cgi?id=9321
>
> for more information.
That's a pretty unhelpful thing. It doesn't describe the breakage at all,
so there is hardly much "more info".
You've also apparently made all the
On Wed, Nov 14, 2007 at 11:54:16AM -0800, Linus Torvalds wrote:
> Actually, I'm pretty happy reverting patches that cause regressions even
> if it *can* be "fixed for release". If there isn't a fix available within
> a day or two, it should get reverted.
> ...
> Also, please notice the latter
Denys Vlasenko wrote:
> hi Matthew,
>
> On Wednesday 14 November 2007 06:35, Hannes Reinecke wrote:
>> Matthew Wilcox wrote:
>>> On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote:
Finally they replied and asked to rediff it against their
git tree. I did that and sent
hi Matthew,
On Wednesday 14 November 2007 06:35, Hannes Reinecke wrote:
> Matthew Wilcox wrote:
> > On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote:
> >> Finally they replied and asked to rediff it against their
> >> git tree. I did that and sent patches back. No reply since then.
1 - 100 of 402 matches
Mail list logo
