> This is assuming your hard drive _itself_ doesn't have bufferbloat, but
> http://spritesmods.com/?art=hddhack=rss implies they don't, and
> tagged command queueing lets you see through that anyway so your
> "actually committed" numbers could presumably still be accurate if the
>
This is assuming your hard drive _itself_ doesn't have bufferbloat, but
http://spritesmods.com/?art=hddhackf=rss implies they don't, and
tagged command queueing lets you see through that anyway so your
actually committed numbers could presumably still be accurate if the
manufacturers
On 10/30/2013 07:01:52 AM, Mel Gorman wrote:
We talked about this a
few months ago but I still suspect that we will have to bite the
bullet and
tune based on "do not dirty more data than it takes N seconds to
writeback"
using per-bdi writeback estimations. It's just not that trivial to
On 10/30/2013 07:01:52 AM, Mel Gorman wrote:
We talked about this a
few months ago but I still suspect that we will have to bite the
bullet and
tune based on do not dirty more data than it takes N seconds to
writeback
using per-bdi writeback estimations. It's just not that trivial to
El Sábado, 26 de octubre de 2013 00:32:25 Fengguang Wu escribió:
> What's the kernel you are running? And it's writing to a hard disk?
> The stalls are most likely caused by either one of
>
> 1) write IO starves read IO
> 2) direct page reclaim blocked when
>- trying to writeout PG_dirty
El Sábado, 26 de octubre de 2013 00:32:25 Fengguang Wu escribió:
What's the kernel you are running? And it's writing to a hard disk?
The stalls are most likely caused by either one of
1) write IO starves read IO
2) direct page reclaim blocked when
- trying to writeout PG_dirty pages
On Mon 11-11-13 14:22:11, Dave Chinner wrote:
> On Thu, Nov 07, 2013 at 02:48:06PM +0100, Jan Kara wrote:
> > On Tue 05-11-13 15:12:45, Dave Chinner wrote:
> > > On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
> > > Realistically, there is no "one right answer" for all combinations
On Mon 11-11-13 14:22:11, Dave Chinner wrote:
On Thu, Nov 07, 2013 at 02:48:06PM +0100, Jan Kara wrote:
On Tue 05-11-13 15:12:45, Dave Chinner wrote:
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
Realistically, there is no one right answer for all combinations
of
On Thu, Nov 07, 2013 at 02:48:06PM +0100, Jan Kara wrote:
> On Tue 05-11-13 15:12:45, Dave Chinner wrote:
> > On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
> > > Something simple like “start writing at 16MB dirty on a single file”
> > > would probably avoid a lot of complexity at
On Thu, Nov 07, 2013 at 02:48:06PM +0100, Jan Kara wrote:
On Tue 05-11-13 15:12:45, Dave Chinner wrote:
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
Something simple like “start writing at 16MB dirty on a single file”
would probably avoid a lot of complexity at little
On Tue 05-11-13 15:12:45, Dave Chinner wrote:
> On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
> > Something simple like “start writing at 16MB dirty on a single file”
> > would probably avoid a lot of complexity at little real-world cost.
> > That shouldn’t throttle dirtying
On Tue 05-11-13 15:12:45, Dave Chinner wrote:
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
Something simple like “start writing at 16MB dirty on a single file”
would probably avoid a lot of complexity at little real-world cost.
That shouldn’t throttle dirtying memory
On Tue, 5 Nov 2013, Figo.zhang wrote:
Of course, if you don't use Linux on the desktop you don't really care -
well, I do. Also
not everyone in this world has an UPS - which means such a huge buffer
can lead to a
serious data loss in case of a power blackout.
I don't have a desk (just a
On Tue, 5 Nov 2013, Figo.zhang wrote:
Of course, if you don't use Linux on the desktop you don't really care -
well, I do. Also
not everyone in this world has an UPS - which means such a huge buffer
can lead to a
serious data loss in case of a power blackout.
I don't have a desk (just a
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
>
> On Oct 25, 2013, at 2:18 AM, Linus Torvalds
> wrote:
> > On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov
> > wrote:
> >>
> >> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11
> >> kernel built for the
On Tue, 5 Nov 2013 09:40:55 +0800 "Figo.zhang" wrote:
> > >
> > > Of course, if you don't use Linux on the desktop you don't really care -
> > well, I do. Also
> > > not everyone in this world has an UPS - which means such a huge buffer
> > can lead to a
> > > serious data loss in case of a
On Oct 25, 2013, at 2:18 AM, Linus Torvalds
wrote:
> On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
>>
>> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11
>> kernel built for the i686 (with PAE) and x86-64 architectures. What’s
>> really troubling me is that
Hi!
> >> - temp-files may not be written out at all.
> >>
> >>Quite frankly, if you have multi-hundred-megabyte temptiles, you've
> >> got issues
> > Actually people do stuff like this e.g. when generating ISO images before
> > burning them.
>
> Yes, but then the temp-file is long-lived
Hi!
> > Yes, but then the temp-file is long-lived enough that it *will* hit
> > the disk anyway. So it's only the "create temporary file and pretty
> > much immediately delete it" case that changes behavior (ie compiler
> > assembly files etc).
> >
> > If the temp-file is for something like
On Oct 25, 2013, at 2:18 AM, Linus Torvalds torva...@linux-foundation.org
wrote:
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov t.ar...@lycos.com wrote:
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11
kernel built for the i686 (with PAE) and x86-64 architectures.
On Tue, 5 Nov 2013 09:40:55 +0800 Figo.zhang figo1...@gmail.com wrote:
Of course, if you don't use Linux on the desktop you don't really care -
well, I do. Also
not everyone in this world has an UPS - which means such a huge buffer
can lead to a
serious data loss in case of a
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote:
On Oct 25, 2013, at 2:18 AM, Linus Torvalds torva...@linux-foundation.org
wrote:
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov t.ar...@lycos.com
wrote:
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the
Hi!
Yes, but then the temp-file is long-lived enough that it *will* hit
the disk anyway. So it's only the create temporary file and pretty
much immediately delete it case that changes behavior (ie compiler
assembly files etc).
If the temp-file is for something like burning an ISO
Hi!
- temp-files may not be written out at all.
Quite frankly, if you have multi-hundred-megabyte temptiles, you've
got issues
Actually people do stuff like this e.g. when generating ISO images before
burning them.
Yes, but then the temp-file is long-lived enough that it
// Sorry for the late response! I'm in marriage leave these days. :)
On Tue, Oct 29, 2013 at 03:42:08PM -0700, Linus Torvalds wrote:
> On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara wrote:
> >
> > So I think we both realize this is only about what the default should be.
>
> Yes. Most people will
On Thu 31-10-13 14:26:12, Karl Kiniger wrote:
> On Tue 131029, Jan Kara wrote:
> > On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
> > > On Fri 131025, Linus Torvalds wrote:
>
> > > Is it currently possible to somehow set above values per block device?
> > Yes, to some extent. You can set
On Thu 31-10-13 14:26:12, Karl Kiniger wrote:
On Tue 131029, Jan Kara wrote:
On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
On Fri 131025, Linus Torvalds wrote:
Is it currently possible to somehow set above values per block device?
Yes, to some extent. You can set
// Sorry for the late response! I'm in marriage leave these days. :)
On Tue, Oct 29, 2013 at 03:42:08PM -0700, Linus Torvalds wrote:
On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara j...@suse.cz wrote:
So I think we both realize this is only about what the default should be.
Yes. Most people
On Tue 131029, Jan Kara wrote:
> On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
> > On Fri 131025, Linus Torvalds wrote:
> > Is it currently possible to somehow set above values per block device?
> Yes, to some extent. You can set /sys/block//bdi/max_ratio to
> the maximum proportion the
On Tue 131029, Jan Kara wrote:
On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
On Fri 131025, Linus Torvalds wrote:
Is it currently possible to somehow set above values per block device?
Yes, to some extent. You can set /sys/block/device/bdi/max_ratio to
the maximum proportion the
On Wed 30-10-13 10:07:08, Artem S. Tashkinov wrote:
> Oct 30, 2013 02:41:01 AM, Jack wrote:
> On Fri 25-10-13 19:37:53, Ted Tso wrote:
> >> Sure, although I wonder if it would be worth it calcuate some kind of
> >> rolling average of the write bandwidth while we are doing writeback,
> >> so if it
On Tue, Oct 29, 2013 at 09:57:56PM +0100, Jan Kara wrote:
> On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
> > On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
> > wrote:
> > >
> > > Apparently all this stuff isn't working as desired (and perhaps as
> > > designed)
> > > in this case. Will take
Oct 30, 2013 02:41:01 AM, Jack wrote:
On Fri 25-10-13 19:37:53, Ted Tso wrote:
>> Sure, although I wonder if it would be worth it calcuate some kind of
>> rolling average of the write bandwidth while we are doing writeback,
>> so if it turns out we got unlucky with the contents of the first 100MB
Oct 30, 2013 02:41:01 AM, Jack wrote:
On Fri 25-10-13 19:37:53, Ted Tso wrote:
Sure, although I wonder if it would be worth it calcuate some kind of
rolling average of the write bandwidth while we are doing writeback,
so if it turns out we got unlucky with the contents of the first 100MB
of
On Tue, Oct 29, 2013 at 09:57:56PM +0100, Jan Kara wrote:
On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
a...@linux-foundation.org wrote:
Apparently all this stuff isn't working as desired (and perhaps as
designed)
in this case.
On Wed 30-10-13 10:07:08, Artem S. Tashkinov wrote:
Oct 30, 2013 02:41:01 AM, Jack wrote:
On Fri 25-10-13 19:37:53, Ted Tso wrote:
Sure, although I wonder if it would be worth it calcuate some kind of
rolling average of the write bandwidth while we are doing writeback,
so if it turns out
On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara wrote:
>
> So I think we both realize this is only about what the default should be.
Yes. Most people will use the defaults, but there will always be
people who tune things for particular loads.
In fact, I think we have gone much too far in saying
On Tue 29-10-13 14:33:53, Linus Torvalds wrote:
> On Tue, Oct 29, 2013 at 1:57 PM, Jan Kara wrote:
> > On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
> >>
> >> It definitely doesn't work. I can trivially reproduce problems by just
> >> having a cheap (==slow) USB key with an ext3 filesystem, and
On Tue, Oct 29, 2013 at 1:43 PM, Andrew Morton
wrote:
> On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara wrote:
>
>> Andrew has queued up a patch series from Maxim Patlasov which removes this
>> caveat but currently we don't have a way admin can switch that from
>> userspace. But I'd like to have
On Tue, Oct 29, 2013 at 1:57 PM, Jan Kara wrote:
> On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
>>
>> It definitely doesn't work. I can trivially reproduce problems by just
>> having a cheap (==slow) USB key with an ext3 filesystem, and going a
>> git clone to it. The end result is not pretty,
On Tue 29-10-13 13:43:46, Andrew Morton wrote:
> On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara wrote:
>
> > Andrew has queued up a patch series from Maxim Patlasov which removes this
> > caveat but currently we don't have a way admin can switch that from
> > userspace. But I'd like to have that
On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
> On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
> wrote:
> >
> > Apparently all this stuff isn't working as desired (and perhaps as designed)
> > in this case. Will take a look after a return to normalcy ;)
>
> It definitely doesn't work. I can
On Fri 25-10-13 18:26:23, Artem S. Tashkinov wrote:
> Oct 25, 2013 05:26:45 PM, david wrote:
> On Fri, 25 Oct 2013, NeilBrown wrote:
> >
> >>
> >> What exactly is bothering you about this? The amount of memory used or the
> >> time until data is flushed?
> >
> >actually, I think the problem is
On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara wrote:
> Andrew has queued up a patch series from Maxim Patlasov which removes this
> caveat but currently we don't have a way admin can switch that from
> userspace. But I'd like to have that tunable from userspace exactly for the
> cases as you
On Fri 25-10-13 19:37:53, Ted Tso wrote:
> On Sat, Oct 26, 2013 at 12:05:45AM +0100, Fengguang Wu wrote:
> >
> > Ted, when trying to follow up your email, I got a crazy idea and it'd
> > be better throw it out rather than carrying it to bed. :)
> >
> > We could do per-bdi dirty thresholds -
On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
> On Fri 131025, Linus Torvalds wrote:
> > On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov
> > wrote:
> > >
> > > My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_
> > > be
> > > percentage based, 'cause for PCs/servers
On Fri 25-10-13 11:15:55, Karl Kiniger wrote:
On Fri 131025, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov t.ar...@lycos.com
wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_
be
percentage based, 'cause for PCs/servers
On Fri 25-10-13 19:37:53, Ted Tso wrote:
On Sat, Oct 26, 2013 at 12:05:45AM +0100, Fengguang Wu wrote:
Ted, when trying to follow up your email, I got a crazy idea and it'd
be better throw it out rather than carrying it to bed. :)
We could do per-bdi dirty thresholds - which has been
On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara j...@suse.cz wrote:
Andrew has queued up a patch series from Maxim Patlasov which removes this
caveat but currently we don't have a way admin can switch that from
userspace. But I'd like to have that tunable from userspace exactly for the
cases as
On Fri 25-10-13 18:26:23, Artem S. Tashkinov wrote:
Oct 25, 2013 05:26:45 PM, david wrote:
On Fri, 25 Oct 2013, NeilBrown wrote:
What exactly is bothering you about this? The amount of memory used or the
time until data is flushed?
actually, I think the problem is more the impact of
On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
a...@linux-foundation.org wrote:
Apparently all this stuff isn't working as desired (and perhaps as designed)
in this case. Will take a look after a return to normalcy ;)
It definitely
On Tue 29-10-13 13:43:46, Andrew Morton wrote:
On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara j...@suse.cz wrote:
Andrew has queued up a patch series from Maxim Patlasov which removes this
caveat but currently we don't have a way admin can switch that from
userspace. But I'd like to have
On Tue, Oct 29, 2013 at 1:57 PM, Jan Kara j...@suse.cz wrote:
On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
It definitely doesn't work. I can trivially reproduce problems by just
having a cheap (==slow) USB key with an ext3 filesystem, and going a
git clone to it. The end result is not
On Tue, Oct 29, 2013 at 1:43 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Tue, 29 Oct 2013 21:30:50 +0100 Jan Kara j...@suse.cz wrote:
Andrew has queued up a patch series from Maxim Patlasov which removes this
caveat but currently we don't have a way admin can switch that from
On Tue 29-10-13 14:33:53, Linus Torvalds wrote:
On Tue, Oct 29, 2013 at 1:57 PM, Jan Kara j...@suse.cz wrote:
On Fri 25-10-13 10:32:16, Linus Torvalds wrote:
It definitely doesn't work. I can trivially reproduce problems by just
having a cheap (==slow) USB key with an ext3 filesystem, and
On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara j...@suse.cz wrote:
So I think we both realize this is only about what the default should be.
Yes. Most people will use the defaults, but there will always be
people who tune things for particular loads.
In fact, I think we have gone much too far in
On Sat, Oct 26, 2013 at 4:32 AM, Pavel Machek wrote:
>
> Hmm, I'd expect the result to be "dead USB key". Putting
> ext3 on cheap flash device normally just kills the devic :-(.
Not my experience. It may be true for some really cheap devices, but
normal USB keys seem to just get really slow,
On Fri 2013-10-25 10:32:16, Linus Torvalds wrote:
> On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
> wrote:
> >
> > Apparently all this stuff isn't working as desired (and perhaps as designed)
> > in this case. Will take a look after a return to normalcy ;)
>
> It definitely doesn't work. I
On Fri 2013-10-25 10:32:16, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
a...@linux-foundation.org wrote:
Apparently all this stuff isn't working as desired (and perhaps as designed)
in this case. Will take a look after a return to normalcy ;)
It definitely
On Sat, Oct 26, 2013 at 4:32 AM, Pavel Machek pa...@ucw.cz wrote:
Hmm, I'd expect the result to be dead USB key. Putting
ext3 on cheap flash device normally just kills the devic :-(.
Not my experience. It may be true for some really cheap devices, but
normal USB keys seem to just get really
On Sat, Oct 26, 2013 at 12:05:45AM +0100, Fengguang Wu wrote:
>
> Ted, when trying to follow up your email, I got a crazy idea and it'd
> be better throw it out rather than carrying it to bed. :)
>
> We could do per-bdi dirty thresholds - which has been proposed 1-2
> times before by different
On Fri, Oct 25, 2013 at 09:40:13PM +0200, Diego Calleja wrote:
> El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió:
> > Oct 25, 2013 05:26:45 PM, david wrote:
> > >actually, I think the problem is more the impact of the huge write later
> > >on.
> > Exactly. And not being able
On Fri, Oct 25, 2013 at 05:18:42AM -0400, Theodore Ts'o wrote:
> On Fri, Oct 25, 2013 at 08:30:53AM +, Artem S. Tashkinov wrote:
> > My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
> > percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
> >
On Fri, Oct 25, 2013 at 02:29:37AM -0700, Andrew Morton wrote:
> On Fri, 25 Oct 2013 05:18:42 -0400 "Theodore Ts'o" wrote:
>
> > What I think would make sense is to dynamically measure the speed of
> > writeback, so that we can set these limits as a function of the device
> > speed.
>
> We
On Fri, 25 Oct 2013 21:03:44 + (UTC) "Artem S. Tashkinov"
wrote:
> Oct 26, 2013 02:44:07 AM, neil wrote:
> On Fri, 25 Oct 2013 18:26:23 + (UTC) "Artem S. Tashkinov"
> >>
> >> Exactly. And not being able to use applications which show you IO
> >> performance
> >> like Midnight
Oct 26, 2013 02:44:07 AM, neil wrote:
On Fri, 25 Oct 2013 18:26:23 + (UTC) "Artem S. Tashkinov"
>>
>> Exactly. And not being able to use applications which show you IO performance
>> like Midnight Commander. You might prefer to use "cp -a" but I cannot imagine
>> my life without being able to
On Fri, 25 Oct 2013 18:26:23 + (UTC) "Artem S. Tashkinov"
wrote:
> Oct 25, 2013 05:26:45 PM, david wrote:
> On Fri, 25 Oct 2013, NeilBrown wrote:
> >
> >>
> >> What exactly is bothering you about this? The amount of memory used or the
> >> time until data is flushed?
> >
> >actually, I
El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió:
> Oct 25, 2013 05:26:45 PM, david wrote:
> >actually, I think the problem is more the impact of the huge write later
> >on.
> Exactly. And not being able to use applications which show you IO
> performance like Midnight
Oct 25, 2013 05:26:45 PM, david wrote:
On Fri, 25 Oct 2013, NeilBrown wrote:
>
>>
>> What exactly is bothering you about this? The amount of memory used or the
>> time until data is flushed?
>
>actually, I think the problem is more the impact of the huge write later on.
Exactly. And not being
On Fri, 25 Oct 2013, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more) this value becomes unrealistic
On Fri, 25 Oct 2013, NeilBrown wrote:
On Fri, 25 Oct 2013 07:25:13 + (UTC) "Artem S. Tashkinov"
wrote:
Hello!
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling
me
is that the
On Fri, 25 Oct 2013 07:25:13 + (UTC) "Artem S. Tashkinov"
wrote:
> Hello!
>
> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
> built for the i686 (with PAE) and x86-64 architectures. What's really
> troubling me
> is that the x86-64 kernel has the following
On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
wrote:
>
> Apparently all this stuff isn't working as desired (and perhaps as designed)
> in this case. Will take a look after a return to normalcy ;)
It definitely doesn't work. I can trivially reproduce problems by just
having a cheap (==slow)
On Fri, 25 Oct 2013 05:18:42 -0400 "Theodore Ts'o" wrote:
> What I think would make sense is to dynamically measure the speed of
> writeback, so that we can set these limits as a function of the device
> speed.
We attempt to do this now - have a look through struct backing_dev_info.
Apparently
On Fri, Oct 25, 2013 at 08:30:53AM +, Artem S. Tashkinov wrote:
> My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
> percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
> more) this value becomes unrealistic (13GB) and I've already had some
>
On Fri 131025, Linus Torvalds wrote:
> On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov wrote:
> >
> > My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
> > percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
> > more) this value becomes
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov wrote:
>
> My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
> percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
> more) this value becomes unrealistic (13GB) and I've already had some
>
Oct 25, 2013 02:18:50 PM, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
>>
>> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
>> built for the i686 (with PAE) and x86-64 architectures. What's really
>> troubling me
>> is that the
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
>
> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
> built for the i686 (with PAE) and x86-64 architectures. What's really
> troubling me
> is that the x86-64 kernel has the following problem:
>
> When I copy
Hello!
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling
me
is that the x86-64 kernel has the following problem:
When I copy large files to any storage device, be it my HDD with ext4
Hello!
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling
me
is that the x86-64 kernel has the following problem:
When I copy large files to any storage device, be it my HDD with ext4
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov t.ar...@lycos.com wrote:
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really
troubling me
is that the x86-64 kernel has the following problem:
Oct 25, 2013 02:18:50 PM, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really
troubling me
is that the x86-64 kernel
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov t.ar...@lycos.com wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more) this value becomes unrealistic (13GB) and I've already had
On Fri 131025, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov t.ar...@lycos.com wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more) this value becomes
On Fri, Oct 25, 2013 at 08:30:53AM +, Artem S. Tashkinov wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more) this value becomes unrealistic (13GB) and I've already had some
On Fri, 25 Oct 2013 05:18:42 -0400 Theodore Ts'o ty...@mit.edu wrote:
What I think would make sense is to dynamically measure the speed of
writeback, so that we can set these limits as a function of the device
speed.
We attempt to do this now - have a look through struct backing_dev_info.
On Fri, Oct 25, 2013 at 10:29 AM, Andrew Morton
a...@linux-foundation.org wrote:
Apparently all this stuff isn't working as desired (and perhaps as designed)
in this case. Will take a look after a return to normalcy ;)
It definitely doesn't work. I can trivially reproduce problems by just
On Fri, 25 Oct 2013 07:25:13 + (UTC) Artem S. Tashkinov
t.ar...@lycos.com wrote:
Hello!
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really
troubling me
is that the x86-64 kernel has the
On Fri, 25 Oct 2013, NeilBrown wrote:
On Fri, 25 Oct 2013 07:25:13 + (UTC) Artem S. Tashkinov
t.ar...@lycos.com wrote:
Hello!
On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling
me
is
On Fri, 25 Oct 2013, Linus Torvalds wrote:
On Fri, Oct 25, 2013 at 9:30 AM, Artem S. Tashkinov t.ar...@lycos.com wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more) this value
Oct 25, 2013 05:26:45 PM, david wrote:
On Fri, 25 Oct 2013, NeilBrown wrote:
What exactly is bothering you about this? The amount of memory used or the
time until data is flushed?
actually, I think the problem is more the impact of the huge write later on.
Exactly. And not being able to use
El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió:
Oct 25, 2013 05:26:45 PM, david wrote:
actually, I think the problem is more the impact of the huge write later
on.
Exactly. And not being able to use applications which show you IO
performance like Midnight Commander.
On Fri, 25 Oct 2013 18:26:23 + (UTC) Artem S. Tashkinov
t.ar...@lycos.com wrote:
Oct 25, 2013 05:26:45 PM, david wrote:
On Fri, 25 Oct 2013, NeilBrown wrote:
What exactly is bothering you about this? The amount of memory used or the
time until data is flushed?
actually, I think
Oct 26, 2013 02:44:07 AM, neil wrote:
On Fri, 25 Oct 2013 18:26:23 + (UTC) Artem S. Tashkinov
Exactly. And not being able to use applications which show you IO performance
like Midnight Commander. You might prefer to use cp -a but I cannot imagine
my life without being able to see the
On Fri, 25 Oct 2013 21:03:44 + (UTC) Artem S. Tashkinov
t.ar...@lycos.com wrote:
Oct 26, 2013 02:44:07 AM, neil wrote:
On Fri, 25 Oct 2013 18:26:23 + (UTC) Artem S. Tashkinov
Exactly. And not being able to use applications which show you IO
performance
like Midnight Commander.
On Fri, Oct 25, 2013 at 02:29:37AM -0700, Andrew Morton wrote:
On Fri, 25 Oct 2013 05:18:42 -0400 Theodore Ts'o ty...@mit.edu wrote:
What I think would make sense is to dynamically measure the speed of
writeback, so that we can set these limits as a function of the device
speed.
We
On Fri, Oct 25, 2013 at 05:18:42AM -0400, Theodore Ts'o wrote:
On Fri, Oct 25, 2013 at 08:30:53AM +, Artem S. Tashkinov wrote:
My feeling is that vm.dirty_ratio/vm.dirty_background_ratio should _not_ be
percentage based, 'cause for PCs/servers with a lot of memory (say 64GB or
more)
On Fri, Oct 25, 2013 at 09:40:13PM +0200, Diego Calleja wrote:
El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió:
Oct 25, 2013 05:26:45 PM, david wrote:
actually, I think the problem is more the impact of the huge write later
on.
Exactly. And not being able to use
On Sat, Oct 26, 2013 at 12:05:45AM +0100, Fengguang Wu wrote:
Ted, when trying to follow up your email, I got a crazy idea and it'd
be better throw it out rather than carrying it to bed. :)
We could do per-bdi dirty thresholds - which has been proposed 1-2
times before by different people.
100 matches
Mail list logo
