mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cantab.net>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: vda@port.imtp.ilyichevsk.odessa.ua,
	Rusty Russell <rusty@rustcorp.com.au>,
	torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	k-suganuma@mvj.biglobe.ne.jp, Andrew Morton <akpm@zip.com.au>
Subject: Re: [PATCH] 2.5.21 Nonlinear CPU support
Date: Wed, 12 Jun 2002 21:41:56 +0100	[thread overview]
Message-ID: <5.1.0.14.2.20020612213746.045b7b60@pop.cus.cam.ac.uk> (raw)
In-Reply-To: <20020612193921.GA682@clusterfs.com>

At 20:39 12/06/02, Andreas Dilger wrote:
>On Jun 12, 2002  19:34 +0100, Anton Altaparmakov wrote:
> > At 18:36 12/06/02, Andreas Dilger wrote:
> > >1) Allocate an array of NULL pointers which is NR_CPUs in size (you could
> > >   do this all the time, as it would only be a few bytes)
> >
> > Yes, that is fine.
> >
> > >2) If you need to do decompression on a cpu you check the array entry
> > >   for that CPU and if is NULL you vmalloc() the decompression buffers 
> once
> > >   for that CPU.  This avoid vmalloc() overhead for each read.
> >
> > The vmalloc() sleeps and by the time you get control back you are 
> executing
> > on a different CPU. Ooops. The only valid way of treating per-cpu data is:
> >
> > - disable preemption
> > - get the cpu number = START OF CRITICAL SECTION: no sleep/schedule allowed
> > - do work using the cpu number
> > - reenable preemption = END OF CRITICAL SECTION
> >
> > The only thing that could possibly be used inside the critical region is
> > kmalloc(GFP_ATOMIC) but we are allocating 64kiB so that is not an option.
> > (It would fail very quickly due to memory fragmentation, the order of the
> > allocation is too high.)
>
>Well, then you can still do the one-time allocation for that CPU slot,
>and re-check the CPU number after vmalloc() returns.  If it is different
>(or always, for that matter) then you jump back to the "is the array for
>this CPU allocated" check until the array _is_ allocated for that CPU
>and you don't need to allocate it (so you won't sleep).  At most you
>will need to loop once for each available CPU if you are unlucky enough
>to be rescheduled to a different CPU after each call to vmalloc().
>
>Like:
>         int cpunum = this_cpu();
>         char *newbuf = NULL;
>
>         while (unlikely(NTFS_SB(sb)->s_compr_array[cpunum] == NULL)) {

Um are you suggesting compression buffers to be per mounted volume? That 
would be more wasteful than the current approach of one buffer per CPU 
globally for all of ntfs driver.

>                 newbuf = vmalloc(NTFS_DECOMPR_BUFFER_SIZE);
>
>                 /* Re-check the buffer case we slept in vmalloc() and
>                 * someone else already allocated a buffer for "this" CPU.
>                 */
>                 if (likely(NTFS_SB(sb)->s_compr_array[cpunum] == NULL)) {
>                         NTFS_SB(sb)->s_compr_array[cpunum] = newbuf;
>                         newbuf = NULL;
>                 }
>                 cpunum = this_cpu();
>         }
>         /* Hmm, we slept in vmalloc and we don't need the new buffer */
>         if (unlikely(newbuf != NULL))
>                 vfree(newbuf);

vfree() at a guess (I may be completely wrong on that one in which case I 
appologize!) can also sleep so that breaks that scheme.

> > >3) Any allocated buffers are freed in the same manner they are now -
> > >   when the last compressed volume is unmounted.  There may be some or
> > >   all entries that are still NULL.
> > >
> > >This also avoids allocating buffers when there are no files which are
> > >actually compressed.
> >
> > True it does, but unfortunately it doesn't work. )-:
>
>Now it does... ;-).

Perhaps. But if doing something like that I might as well use the present 
approach and just allocate all buffers at once if they haven't been 
allocated yet and be done with it. Then no vfree()s are needed either and 
then it really does work. (-;

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/


  reply	other threads:[~2002-06-12 20:41 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-11  7:08 Rusty Russell
2002-06-11  7:42 ` Andrew Morton
2002-06-11  9:09   ` Rusty Russell
2002-06-11  9:10     ` David S. Miller
2002-06-12  6:58       ` Rusty Russell
2002-06-12  9:26         ` David S. Miller
2002-06-13  5:01           ` Rusty Russell
2002-06-13  5:55             ` David S. Miller
2002-06-11  9:27     ` Andrew Morton
2002-06-11 11:22       ` Anton Altaparmakov
2002-06-12  5:57         ` Rusty Russell
2002-06-12  7:54           ` Anton Altaparmakov
2002-06-12  8:06             ` Rusty Russell
2002-06-12  8:25               ` Anton Altaparmakov
2002-06-12 19:32                 ` Linus Torvalds
2002-06-12 13:10               ` Mikael Pettersson
2002-06-13  2:42                 ` Rusty Russell
2002-06-12  0:53       ` Rusty Russell
2002-06-12  8:36       ` Helge Hafting
2002-06-11 10:57   ` Anton Altaparmakov
2002-06-11 17:59     ` Robert Love
2002-06-12  4:11       ` Rusty Russell
2002-06-11 19:29     ` Denis Vlasenko
2002-06-11 14:54       ` Anton Altaparmakov
2002-06-12 19:32         ` Denis Vlasenko
2002-06-12 15:08           ` Anton Altaparmakov
2002-06-12 17:36             ` Andreas Dilger
2002-06-12 18:34               ` Anton Altaparmakov
2002-06-12 19:39                 ` Andreas Dilger
2002-06-12 20:41                   ` Anton Altaparmakov [this message]
2002-06-12 21:03                     ` Andreas Dilger
2002-06-12 21:15                       ` Anton Altaparmakov
2002-06-12 20:03                 ` H. Peter Anvin
2002-06-12 20:54                   ` Robert Love
2002-06-12 20:57                   ` Anton Altaparmakov
2002-06-12 22:21                     ` H. Peter Anvin
2002-06-13  1:33                       ` Anton Altaparmakov
2002-06-13  1:38                         ` H. Peter Anvin
2002-06-13  1:45                           ` Anton Altaparmakov
2002-06-13  2:13                             ` H. Peter Anvin
2002-06-13  2:21                               ` Anton Altaparmakov
2002-06-13  8:43                             ` Helge Hafting
2002-06-11 18:01       ` Robert Love
2002-06-12  7:57 ` Alan Cox
2002-06-12  8:01   ` Rusty Russell
     [not found] <Pine.LNX.4.33.0206121226550.1533-100000@penguin.transmeta. com>
2002-06-12 21:29 ` Anton Altaparmakov

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=5.1.0.14.2.20020612213746.045b7b60@pop.cus.cam.ac.uk \
    --to=aia21@cantab.net \
    --cc=adilger@clusterfs.com \
    --cc=akpm@zip.com.au \
    --cc=k-suganuma@mvj.biglobe.ne.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@transmeta.com \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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

all inboxes | Powered by JetHome®