public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Anton Altaparmakov <aia21@cantab.net>
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 13:39:21 -0600	[thread overview]
Message-ID: <20020612193921.GA682@clusterfs.com> (raw)
In-Reply-To: <5.1.0.14.2.20020612155646.048fd520@pop.cus.cam.ac.uk> <5.1.0.14.2.20020611155046.00af3980@pop.cus.cam.ac.uk> <5.1.0.14.2.20020611114701.00aefec0@pop.cus.cam.ac.uk> <5.1.0.14.2.20020611155046.00af3980@pop.cus.cam.ac.uk> <5.1.0.14.2.20020612155646.048fd520@pop.cus.cam.ac.uk> <5.1.0.14.2.20020612192802.045b08c0@pop.cus.cam.ac.uk>

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)) {
		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);

> >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... ;-).

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


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

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-11  7:08 [PATCH] 2.5.21 Nonlinear CPU support 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 [this message]
2002-06-12 20:41                   ` Anton Altaparmakov
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=20020612193921.GA682@clusterfs.com \
    --to=adilger@clusterfs.com \
    --cc=aia21@cantab.net \
    --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