Andrea Arcangeli wrote:
On Wed, Aug 22, 2007 at 01:05:13PM +0200, Andi Kleen wrote:
Ok perhaps the new adaptive dirty limits helps your single disk
a lot too. But your improvements seem to be more "collateral damage" @)
But if that was true it might be enough to just change the dirty limits
to
Andrea Arcangeli wrote:
On Wed, Aug 22, 2007 at 01:05:13PM +0200, Andi Kleen wrote:
Ok perhaps the new adaptive dirty limits helps your single disk
a lot too. But your improvements seem to be more collateral damage @)
But if that was true it might be enough to just change the dirty limits
to
> I am just now playing with dirty_ratio. Anybody knows what the lower
> limit is? "0" seems acceptabel, but does it actually imply "write out
> immediatelly"?
You should "watch -n 1 cat /proc/meminfo" and monitor the Dirty and Writeback
while lowering the amount the kernel may keep dirty. The
I am just now playing with dirty_ratio. Anybody knows what the lower
limit is? 0 seems acceptabel, but does it actually imply write out
immediatelly?
You should watch -n 1 cat /proc/meminfo and monitor the Dirty and Writeback
while lowering the amount the kernel may keep dirty. The solution
Andrew Morton linux-foundation.org> writes:
> > Revert "[PATCH] Fix CONFIG_COMPAT_VDSO"
> > This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
> >
> > Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
> > reported in bug #8040. Reverting the above patch solved
Chuck Ebbert wrote:
Leroy van Logchem wrote:
Bisecting went well, after 13 compiles this commit was found:
a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit
commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f
Author: Roland McGrath <[EMAIL PROTECTED]>
Date: Fri Jan 26 00:56:4
Andi Kleen wrote:
Where does it hang exactly? Do you have a boot log?
Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat
3.4.6-3)) #1 SMP Thu Mar 15 11:06:29 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:
Leroy van Logchem wldelft.nl> writes:
>
> Greg KH wrote:
> > On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote:
> >
> >> Revert "[PATCH] Fix CONFIG_COMPAT_VDSO"
> >> This reverts commit a1f3bb9ae4497a2ed3eac773fd7798
Greg KH wrote:
On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote:
Revert "[PATCH] Fix CONFIG_COMPAT_VDSO"
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
reported in bug #8040.
Greg KH wrote:
On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote:
Revert [PATCH] Fix CONFIG_COMPAT_VDSO
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
reported in bug #8040. Reverting
Leroy van Logchem leroy.vanlogchem at wldelft.nl writes:
Greg KH wrote:
On Thu, Mar 15, 2007 at 12:38:40AM +0100, Leroy van Logchem wrote:
Revert [PATCH] Fix CONFIG_COMPAT_VDSO
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot
Andi Kleen wrote:
Where does it hang exactly? Do you have a boot log?
Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat
3.4.6-3)) #1 SMP Thu Mar 15 11:06:29 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:
Chuck Ebbert wrote:
Leroy van Logchem wrote:
Bisecting went well, after 13 compiles this commit was found:
a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit
commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f
Author: Roland McGrath [EMAIL PROTECTED]
Date: Fri Jan 26 00:56:46 2007
Andrew Morton akpm at linux-foundation.org writes:
Revert [PATCH] Fix CONFIG_COMPAT_VDSO
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
reported in bug #8040. Reverting the above patch solved the
Revert "[PATCH] Fix CONFIG_COMPAT_VDSO"
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
reported in bug #8040. Reverting the above patch solved the problem.
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Cc: Ingo
Leroy van Logchem wldelft.nl> writes:
>
> > > None whatsoever. Three people are reporting this and it's a drop-dead
> > > showstopper for a 2.6.21 release so we just have to wait until someone
> > > wakes up and thinks about it.
>
> The topic s
> > None whatsoever. Three people are reporting this and it's a drop-dead
> > showstopper for a 2.6.21 release so we just have to wait until someone
> > wakes up and thinks about it.
The topic should be "when CONFIG_HIGHMEM64G=y" imo.
I'll try to do my first bi-sect today.
--
Leroy
-
To
None whatsoever. Three people are reporting this and it's a drop-dead
showstopper for a 2.6.21 release so we just have to wait until someone
wakes up and thinks about it.
The topic should be when CONFIG_HIGHMEM64G=y imo.
I'll try to do my first bi-sect today.
--
Leroy
-
To unsubscribe
Leroy van Logchem leroy.vanlogchem at wldelft.nl writes:
None whatsoever. Three people are reporting this and it's a drop-dead
showstopper for a 2.6.21 release so we just have to wait until someone
wakes up and thinks about it.
The topic should be when CONFIG_HIGHMEM64G=y imo
Revert [PATCH] Fix CONFIG_COMPAT_VDSO
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.
Several systems couldnt boot using CONFIG_HIGHMEM64G=y as
reported in bug #8040. Reverting the above patch solved the problem.
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Ingo
> > actually a global dirty_ratio causes interference between devices which
> > should otherwise not block each other...
> >
> > if you set up a "dd if=/dev/zero of=/dev/sdb bs=1M" it shouldn't affect
> > write performance on sda -- but it does... because the dd basically
> > dirties all of
actually a global dirty_ratio causes interference between devices which
should otherwise not block each other...
if you set up a dd if=/dev/zero of=/dev/sdb bs=1M it shouldn't affect
write performance on sda -- but it does... because the dd basically
dirties all of the
> I'm sorry to piggy-back this thread.
>
> Could it be what I'm experiencing in the following bugzilla report:
> http://bugzilla.kernel.org/show_bug.cgi?id=7372
>
> As I explained in the report, I see this issue only since 2.6.18.
> So if your concern is related to mine, what could have changed
I'm sorry to piggy-back this thread.
Could it be what I'm experiencing in the following bugzilla report:
http://bugzilla.kernel.org/show_bug.cgi?id=7372
As I explained in the report, I see this issue only since 2.6.18.
So if your concern is related to mine, what could have changed between
Tomoki Sekiyama hitachi.com> writes:
> thanks for your comments.
The default dirty_ratio on most 2.6 kernels tend to be too large imo.
If you are going to do sustained writes multiple times the size of
the memory you have at least two problems.
1) The precious dentry and inodecache will be
Tomoki Sekiyama tomoki.sekiyama.qu at hitachi.com writes:
thanks for your comments.
The default dirty_ratio on most 2.6 kernels tend to be too large imo.
If you are going to do sustained writes multiple times the size of
the memory you have at least two problems.
1) The precious dentry and
26 matches
Mail list logo
