Hi,
Thank you for your comments.
Leroy van Logchem wrote:
>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 dropped
Hi,
Thank you for your comments.
Leroy van Logchem wrote:
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 dropped
Hi,
On Fri, 2007-03-02 at 13:06 +, Leroy van Logchem wrote:
> > 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
> 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
Hi,
On Thu, 2007-03-01 at 12:47 +, Leroy van Logchem wrote:
> 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
Hi,
On Thu, 2007-03-01 at 12:47 +, Leroy van Logchem wrote:
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
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
Hi,
On Fri, 2007-03-02 at 13:06 +, Leroy van Logchem wrote:
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.
Hi Kamezawa-san,
KAMEZAWA Hiroyuki wrote:
>>> Interesting, but how about adjust this parameter like below instead of
>>> adding new control knob ?(this kind of knob is not easy to use.)
>>> count_dirty_pages_on_device_limited(bdi, writechunk) above returns
>>> dirty pages on bdi. if # of
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
Hi Kamezawa-san,
KAMEZAWA Hiroyuki wrote:
Interesting, but how about adjust this parameter like below instead of
adding new control knob ?(this kind of knob is not easy to use.)
snip
count_dirty_pages_on_device_limited(bdi, writechunk) above returns
dirty pages on bdi. if # of dirty_pages
On Tue, 27 Feb 2007 09:50:16 +0900
Tomoki Sekiyama <[EMAIL PROTECTED]> wrote:
> Hi Kamezawa-san,
>
> thanks for your reply.
>
> KAMEZAWA Hiroyuki wrote:
> > Interesting, but how about adjust this parameter like below instead of
> > adding new control knob ?(this kind of knob is not easy to
Hi Nikita,
thanks for your comments.
Nikita Danilov wrote:
>> While Dirty+Writeback pages get more than 40% of memory, process-B is
>> blocked in balance_dirty_pages() until writeback of some (`write_chunk',
>> typically = 1536) dirty pages on disk-b is started.
>
> May be the simpler solution
Hi Kamezawa-san,
thanks for your reply.
KAMEZAWA Hiroyuki wrote:
> Interesting, but how about adjust this parameter like below instead of
> adding new control knob ?(this kind of knob is not easy to use.)
>
> ==
> struct writeback_control wbc = {
> .bdi
Hi Kamezawa-san,
thanks for your reply.
KAMEZAWA Hiroyuki wrote:
Interesting, but how about adjust this parameter like below instead of
adding new control knob ?(this kind of knob is not easy to use.)
==
struct writeback_control wbc = {
.bdi
Hi Nikita,
thanks for your comments.
Nikita Danilov wrote:
While Dirty+Writeback pages get more than 40% of memory, process-B is
blocked in balance_dirty_pages() until writeback of some (`write_chunk',
typically = 1536) dirty pages on disk-b is started.
May be the simpler solution is to use
On Tue, 27 Feb 2007 09:50:16 +0900
Tomoki Sekiyama [EMAIL PROTECTED] wrote:
Hi Kamezawa-san,
thanks for your reply.
KAMEZAWA Hiroyuki wrote:
Interesting, but how about adjust this parameter like below instead of
adding new control knob ?(this kind of knob is not easy to use.)
==
Tomoki Sekiyama writes:
> Hi,
Hello,
>
[...]
>
> While Dirty+Writeback pages get more than 40% of memory, process-B is
> blocked in balance_dirty_pages() until writeback of some (`write_chunk',
> typically = 1536) dirty pages on disk-b is started.
May be the simpler solution is to use
Tomoki Sekiyama writes:
Hi,
Hello,
[...]
While Dirty+Writeback pages get more than 40% of memory, process-B is
blocked in balance_dirty_pages() until writeback of some (`write_chunk',
typically = 1536) dirty pages on disk-b is started.
May be the simpler solution is to use
On Fri, 23 Feb 2007 21:03:37 +0900
Tomoki Sekiyama <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have observed a problem that write(2) can be blocked for a long time
> if a system has several disks and is under heavy I/O pressure. This
> patchset is to avoid the problem.
>
> Example of the probrem:
>
Hi,
I have observed a problem that write(2) can be blocked for a long time
if a system has several disks and is under heavy I/O pressure. This
patchset is to avoid the problem.
Example of the probrem:
There are two processes on a system which has two disks. Process-A
writes heavily to disk-a,
Hi,
I have observed a problem that write(2) can be blocked for a long time
if a system has several disks and is under heavy I/O pressure. This
patchset is to avoid the problem.
Example of the probrem:
There are two processes on a system which has two disks. Process-A
writes heavily to disk-a,
On Fri, 23 Feb 2007 21:03:37 +0900
Tomoki Sekiyama [EMAIL PROTECTED] wrote:
Hi,
I have observed a problem that write(2) can be blocked for a long time
if a system has several disks and is under heavy I/O pressure. This
patchset is to avoid the problem.
Example of the probrem:
There
24 matches
Mail list logo
