> This is assuming your hard drive _itself_ doesn't have bufferbloat, but
> http://spritesmods.com/?art=hddhack&f=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
> manufac
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
impl
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 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 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 memor
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 l
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 power
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 the
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 en
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 burni
// 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 us
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 /sys
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 dev
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 t
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
>
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 "all
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 that
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 tun
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 t
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 mor
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 descri
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
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 wit
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, prob
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 can
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 pe
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
> > mor
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 attem
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 Commander.
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 think
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 Command
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 abl
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 (13
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 x86-64
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 prob
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) US
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
> un
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 unrealis
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
> unpleasa
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-6
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 partiti
50 matches
Mail list logo
