On Tuesday January 9, [email protected] wrote:
>
> Actually, ext3 doesn't work that way. The atime update will go into the
> "running transaction", which is an instance of journal_t which is separate
> from the committing transaction.
Hmm... fair enough. start_this_handle (which is called eventually
from ext3_dirty_inode) seems to wait for a few different things, and I
jumped to some conclusions.
>
> But there are situations (ie; journal free-space exhaustion) where things
> can go synchronous. They're more likely to occur during metadata storms
> though, and perhaps indicate an undersized journal.
>
> But yeah, overall point agreed with.
Thanks.
> > So this patch removes the minimum of '5' and introduces a new tunable
> > 'vm.dirty_kb' which sets an upper limit in Kibibytes.
>
> kibibytes? We're feeding the kernel catfood now?
:-)
> > and journal commits). The symptoms are:
> > While generating constant write traffic on a machine with > 20Gig
> > of RAM, performing assorted read-only operations can sometimes
> > produces a pause of 10s of seconds.
> > The pause can be removed by:
> > - mounting noatime
> > - mounting data=writeback
> > - setting vm.dirty_kb to 1000 with this patch.
>
> Could be IO scheduler borkage, could be ext3 borkage. A well-timed sysrq-T
> will tell us, and is worth doing (please).
>
> Does increasing the journal size help?
No, that was tried.
>
> It would be better if we can avoid creating the second global variable. Is
> it not possible to remove dirty_ratio? Make everything work off
> vm_dirty_kb and do arithmetricks at the /proc/sys/vm/dirty_ratio interface?
Uhmmm... not sure what you are thinking.
I guess we could teach vm.dirty_ratio to take a floating point number
(but does sysctl understand that?) so we could set it to 0.01 or
similar, but that is missing the point in a way. We don't really want
to set a small ratio. We want to set a small maximum number.
It could make lots of sense to have two numbers. A ratio that wins on
a small memory machine and a fixed number that wins on a large memory
machine. Different trade offs are more significant in the different
cases.
>
> We should perform the same conversion to dirty_background_ratio, I suspect.
>
I didn't add a fixed limit for dirty_background_ratio as it seemed
reasonable to assume that (dirty_background_ratio / dirty_ratio) was a
meaningful value, and just multiplied the final 'dirty' figure by this
ration to get the 'background' figure.
> And these guys should be `long', not `int'. Otherwise things will go
> pearshaped at 2 tabbybytes.
I don't think so. You would need to have blindingly fast storage
before there would be any interest in vm_dirty_kb getting anything
close to t*bytes. But I guess we can make it 'unsigned long' if it
helps.
Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
