[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <459d501038de4d25db6d140ac5ea5f8d@mail.ud19.udmedia.de>
Date: Tue, 12 Jul 2016 16:56:32 +0200
From: Matthias Dahl <ml_linux-kernel@...ary-island.eu>
To: Michal Hocko <mhocko@...nel.org>
Cc: linux-raid@...r.kernel.org, linux-mm@...ck.org,
dm-devel@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: Page Allocation Failures/OOM with dm-crypt on software RAID10
(Intel Rapid Storage)
Hello Michal...
On 2016-07-12 16:07, Michal Hocko wrote:
> /proc/slabinfo could at least point on who is eating that memory.
Thanks. I have made another test (and thus again put the RAID10 out of
sync for the 100th time, sigh) and made regular snapshots of slabinfo
which I have attached to this mail.
> Direct IO doesn't get throttled like buffered IO.
Is buffered i/o not used in both cases if I don't explicitly request
direct i/o?
dd if=/dev/zero /dev/md126p5 bs=512K
and dd if=/dev/zero /dev/mapper/test-device bs=512K
Given that the test-device is dm-crypt on md125p5. Aren't both using
buffered i/o?
> the number of pages under writeback was more or less same throughout
> the time but there are some local fluctuations when some pages do get
> completed.
The pages under writeback are those directly destined for the disk, so
after dm-crypt had done its encryption?
> If not you can enable allocator trace point for a particular object
> size (or range of sizes) and see who is requesting them.
If that support is baked into the Fedora provided kernel that is. If
you could give me a few hints or pointers, how to properly do a
allocator
trace point and get some decent data out of it, that would be nice.
Thanks,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
services: custom software [desktop, mobile, web], server administration
Download attachment "slabinfo.txt.gz" of type "application/x-gzip" (30968 bytes)
Powered by blists - more mailing lists