linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: srinivas kandagatla <srinivas.kandagatla@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: RFC: seq_file: optimize memory re-alloc strategy for seq file sizes > PAGE_SIZE
Date: Fri, 15 Jul 2011 17:22:17 +0100	[thread overview]
Message-ID: <CALNtEFhUnf8zvN6CkUsVBBNjQtfn01=2CksPbYfott1MDoW4Vg@mail.gmail.com> (raw)
In-Reply-To: <20110715151843.GB4747@suse.de>

Hi Greg,
Thanks for the comments,
I agree with you on performance vs debugging code.
However actual issue I want to stress on is iterator restarting
multiple times and not the performance.

thanks,
srini

On Fri, Jul 15, 2011 at 4:18 PM, Greg KH <gregkh@suse.de> wrote:
>
> On Fri, Jul 15, 2011 at 09:51:32AM +0100, Srinivas KANDAGATLA wrote:
> > Hi All,
> > I have noticed that, reading or dumping a full sysfs entry (ex:
> > /sys/kernel/debug/gpio )
>
> That's not sysfs, it's debugfs.
>
> > which exceeds PAGE_SIZE restarts associated seq_file iterator
> > (calling start->show->stop)
> > morethan one time.
> >
> > In my case gpio entry just exceeded 8k which resulted in show
> > function getting
> > called 3 times.
> >
> > The reason is because the allocated buffer overflows and seq_file allocates
> > new buffer of next order and starts iteration from the start, which
> > is clear in
> > seq_file code.
> > However this is bit of conservative approach which results in:
> > - restarting iterator if file sz exceeds PAGE_SIZE( which is really
> > not necessary )
> > - not reusing the formated buffer (which can be done by re-alloc and copy).
> > - Will help entires like dumping cacheline or pagetables to capture
> > its state with better accuracy.
> >
> > To address this situation, I think seq_file formating/printf
> > functions should
> > re-allocate buffer as soon as they detect buffer overflow.
>
> This is debugging code, why should performance matter?
>
> > This patch attempts to do the same by adding new function
> > buf_realloc which inturn
> > calls krealloc and all the seq_file formating or printing functions
> > call this
> > function whenever an overflow is detected and retry.
> >
> >
> > Main motive of this patch is to avoid restarting the iterator and NOT
> > performance, however there is a bit of gain in performance too.
> >
> > Performance figures(average over 100 times loop) for different sizes of
> > sysfs entries:
> >
> > without realloc:
> > ---------------------------------
> >   SZ        REAL    USER    SYS
> > ---------------------------------
> > | 4k   | 0.012    0.002    0.009
> > | 8k   | 0.013    0.002    0.010
> > | 16k  | 0.015    0.003    0.012
> > | 32k  | 0.019    0.002    0.017
> > --------------------------------
> >
> > with realloc:
> > ---------------------------------
> >   SZ        REAL    USER    SYS
> > ---------------------------------
> > | 4k  |    0.012    0.002    0.009
> > | 8k  |    0.012    0.002    0.009
> > | 16k |    0.013    0.002    0.010
> > | 32k |    0.015    0.003    0.012
> > -------------------------------
> >
> >
> > I discovered this issue while I was working on a different issue as
> > I happed
> > to stick a printk in show function, which got called 3 times when I
> > dumped the
> > entry with 'cat' :-). which I did not expect.
> >
> >
> > comments? :-)
>
> Again, debugfs doesn't matter for this type of thing, so adding
> complexity to the core kernel code for it shouldn't be done unless
> absolutely needed.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-07-15 16:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-15  8:51 RFC: seq_file: optimize memory re-alloc strategy for seq file sizes > PAGE_SIZE Srinivas KANDAGATLA
2011-07-15 15:18 ` Greg KH
2011-07-15 16:22   ` srinivas kandagatla [this message]
     [not found]   ` <CALNtEFisu-ZkGNFDH=PvOkj=Q=cAbAgMTtMKyMfxh2MVU5kUdw@mail.gmail.com>
2011-07-15 17:02     ` Greg KH
2011-07-15 19:51       ` srinivas kandagatla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALNtEFhUnf8zvN6CkUsVBBNjQtfn01=2CksPbYfott1MDoW4Vg@mail.gmail.com' \
    --to=srinivas.kandagatla@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=srinivas.kandagatla@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).