turn off logs?
quozl at laptop.org
Tue Feb 8 19:58:45 EST 2011
On Tue, Feb 08, 2011 at 12:14:56AM -0500, Martin Langhoff wrote:
> On Tue, Feb 8, 2011 at 12:06 AM, James Cameron <quozl at laptop.org> wrote:
> > the kernel has the right to convert the write into an
> > effectively synchronous operation.
> I am not understanding... can you explain a bit more why it'll turn
You isolated this as part of #10045 discussions on devel@ in May last
year, and my tests confirmed it. It is documented in kernel
Documentation/vm.txt ... "process which is generating disk writes will
itself start writing out dirty data."
> > On XO-1.5, this hurts us badly, because of the
> > random write performance of the internal storage.
> Is there a real-life case in which this is hurting us? I fully follow
> the story on quirky perf profile of our storage, large eraseblocks,
> etc. But small async writes?
You're asking for the frequency of the behaviour. It isn't high unless
there is memory pressure.
On XO-1.5 with 10.1.3 ... using "strace -ff -e write" against olpc-dm,
followed by use of Terminal, Write, and StopWatch activities, filtering
by fd 1 and 2, generated 387 writes, of which only three took more than
1ms. The longest was 24ms.
Adding Record activity, and taking four photographs, and a video, the
total writes is now 5920, and only nine took more than 1ms. Most writes
were below 33us.
An extended usage session would likely see a higher impact, because
free memory would be reduced. I've seen some writes take much longer if
there is already a queue of requests shown by diskstats.
Since these logging writes happen in the middle of anything an activity
does, such as animation or tool tips (I saw warnings about svg's being
read), they can affect latency.
> > I don't see how this could bring Sugar down, please
> > provide more detail
> I mean that oddly-behaved activities can bring Sugar down -- not in
> writing their logs. Now, you do want to write those odd things down
> before Sugar & xorg come down crashing.
> > ?A separate disposable logger process might
> > alleviate your fear.
May I suggest rsyslogd then, it is well known and well isolated. We
already use Python's Logging facility, so we can change handler to
SysLogHandler, and configure rsyslog.conf to write to some place
readable by user olpc.
> > ?It's something for Sugar Labs to consider
> Sugarlabs these days is just where AC + OLPC + a few other (worthy,
> talented, over-committed) hands meet. There is no magic resourceful
> upstream to lean on.
My point being that we're not talking on sugar-devel@
More information about the Devel