On Thu, 12 Jun 2014, Heiko Carstens wrote:
> Yes, that doesn't make any sense. I wrote the patch together in a hurry and
> didn't think much about it.
> So below is the what I think most simple conversion to a vmalloc fallback
> approach for seq files. However the question remains if this seems to
On Wed, 2014-06-11 at 23:52 -0700, David Rientjes wrote:
> On Thu, 12 Jun 2014, Ian Kent wrote:
>
> > > > diff --git a/fs/seq_file.c b/fs/seq_file.c
> > > > index 1d641bb108d2..fca78a04c0d1 100644
> > > > --- a/fs/seq_file.c
> > > > +++ b/fs/seq_file.c
> > > > @@ -8,8 +8,10 @@
> > > > #include
>
On Thu, Jun 12, 2014 at 09:27:41AM +0200, Heiko Carstens wrote:
> On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote:
> > On Thu, 12 Jun 2014, Ian Kent wrote:
> > > > > +static void seq_alloc(struct seq_file *m)
> > > > > +{
> > > > > + m->size = PAGE_SIZE;
> > > > > + m->buf =
On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote:
> On Thu, 12 Jun 2014, Ian Kent wrote:
> > > > +static void seq_alloc(struct seq_file *m)
> > > > +{
> > > > + m->size = PAGE_SIZE;
> > > > + m->buf = kmalloc(m->size, GFP_KERNEL | __GFP_NOWARN);
> > > > + if (!m->buf
On Thu, 12 Jun 2014, Ian Kent wrote:
> > > diff --git a/fs/seq_file.c b/fs/seq_file.c
> > > index 1d641bb108d2..fca78a04c0d1 100644
> > > --- a/fs/seq_file.c
> > > +++ b/fs/seq_file.c
> > > @@ -8,8 +8,10 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
On Wed, 2014-06-11 at 15:29 -0700, David Rientjes wrote:
> On Wed, 11 Jun 2014, Heiko Carstens wrote:
>
> > Alternatively we could also change the seqfile code to fall back to
> > vmalloc allocations. That would probably "fix" all single_open usages
> > where large contiguous memory areas are need
On Wed, 11 Jun 2014, Heiko Carstens wrote:
> Alternatively we could also change the seqfile code to fall back to
> vmalloc allocations. That would probably "fix" all single_open usages
> where large contiguous memory areas are needed and later on fail due
> to memory fragmentation.
> Does anybody
[full quote, since I added Al to cc]
On Mon, Jun 09, 2014 at 04:11:59PM +0800, Ian Kent wrote:
> On Wed, 2014-05-28 at 15:37 -0700, Andrew Morton wrote:
> > On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens
> > wrote:
> >
> > > Now, /proc/stat uses single_open() for showing information. This me
On Wed, 2014-05-28 at 15:37 -0700, Andrew Morton wrote:
> On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens
> wrote:
>
> > Now, /proc/stat uses single_open() for showing information. This means
> > the all data will be gathered and buffered once to a (big) buf.
> >
> > Now, /proc/stat shows sta
On Wed, May 28, 2014 at 03:37:04PM -0700, Andrew Morton wrote:
> On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens
> wrote:
> > With this patch it should not happen anymore that reading /proc/stat
> > fails because of a failing high order memory allocation.
>
> So this deletes the problematic al
On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens
wrote:
> Now, /proc/stat uses single_open() for showing information. This means
> the all data will be gathered and buffered once to a (big) buf.
>
> Now, /proc/stat shows stats per cpu and stats per IRQs. To get information
> in once-shot, it a
From: KAMEZAWA Hiroyuki
Now, /proc/stat uses single_open() for showing information. This means
the all data will be gathered and buffered once to a (big) buf.
Now, /proc/stat shows stats per cpu and stats per IRQs. To get information
in once-shot, it allocates a big buffer (until KMALLOC_MAX_SIZ
12 matches
Mail list logo
