[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] ipc/shm.c: add RSS and swap size information to /proc/sysvipc/shm
    On Thu, 12 Aug 2010 23:33:29 +0200
    Helge Deller <> wrote:

    > On 08/12/2010 10:10 PM, Andrew Morton wrote:
    > > On Wed, 11 Aug 2010 22:13:45 +0200
    > > Helge Deller<> wrote:
    > >
    > >> The kernel currently provides no functionality to analyze the RSS
    > >> and swap space usage of each individual sysvipc shared memory segment.
    > >>
    > >> This patch add this info for each existing shm segment by extending
    > >> the output of /proc/sysvipc/shm by two columns for RSS and swap.
    > >>
    > >> Since shmctl(SHM_INFO) already provides a similiar calculation (it
    > >> currently sums up all RSS/swap info for all segments), I did split
    > >> out a static function which is now used by the /proc/sysvipc/shm
    > >> output and shmctl(SHM_INFO).
    > >>
    > >
    > > I suppose that could be useful, although it would be most interesting
    > > to hear why _you_ consider it useful?
    > A reasonable question, and I really should have explained when I did
    > send this patch.
    > In my job I do work for SAP in the SAP LinuxLab
    > ( and take care of the SAP ERP enterprise
    > software on Linux.
    > SAP products (esp. the SAP Netweaver ABAP Kernel) uses lots of big
    > shared memory segments (we often have Linux systems with >= 16GB shm
    > usage). Sometimes we get customer reports about "slow" system responses
    > and while looking into their configurations we often find massive
    > swapping activity on the system. With this patch it's now easy to see
    > from the command line if and which shm segments gets swapped out (and
    > how much) and can more easily give recommendations for system tuning.
    > Without the patch it's currently not possible to do such shm analysis at
    > all.

    OK, thanks. copied-n-pasted into changelog ;)

    > So, my patch actually does fix a real-world problem.
    > By the way - I found another bug/issue in /proc/<pid>/smaps as well. The
    > kernel currently does not adds swapped-out shm pages to the swap size
    > value correctly. The swap size value always stays zero for shm pages.
    > I'm currently preparing a small patch to fix that, which I will send to
    > linux-mm for review soon.
    > > But is it useful enough to risk breaking existing code which parses
    > > that file? The risk is not great, but it's there.
    > Sure. The only positive argument is maybe, that I added the new info to
    > the end of the lines. IMHO existing applications which parse /proc files
    > should always take into account, that more text could follow with newer
    > Linux kernels...?

    Yeah, they'd be pretty dumb if they failed because new columns appear
    in later kernels.

    But there's some pretty dumb code out there.

    > > This adds 11 new spaces between "perms" and "size", only on 64-bit
    > > machines. That was unchangelogged and adds another (smaller) risk of
    > > breaking things. Please explain.
    > Yes, I did added some spaces in front of the "size" field for 64bit
    > kernels to get the columns correct if you cat the contents of the file.
    > In sysvipc_shm_proc_show() the kernel prints the size value in
    > "SPEC_SIZE" format, which is defined like this:
    > #if BITS_PER_LONG <= 32
    > #define SIZE_SPEC "%10lu"
    > #else
    > #define SIZE_SPEC "%21lu"
    > #endif
    > So, if the header is not adjusted, the columns are not correctly
    > aligned. I actually tested this on 32- and 64-bit and it seems correct now.

    <copy, paste>

     \ /
      Last update: 2010-08-12 23:47    [W:0.025 / U:83.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site