All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Anton Altaparmakov <aia21@mole.bio.cam.ac.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.21 Nonlinear CPU support
Date: Wed, 12 Jun 2002 18:38:31 -0700	[thread overview]
Message-ID: <3D07F797.6030007@zytor.com> (raw)
In-Reply-To: <Pine.SGI.4.33.0206130210170.4638397-100000@mole.bio.cam.ac.uk>

Anton Altaparmakov wrote:
> 
> The code would be run outside the critical region... But correct about
> the race. I thought that was obvious and wasn't suggesting the above to be
> the actual code... That was supposed to be obvious from lack of error
> handling etc... Never mind. My mistake, I should have been more precise
> the first time round, here is the actual code I had in mind:
> 
> [snip]
> 	if (unlikely(!ntfs_compression_buffers)) {
> 		int err;
> 
> 		/*
> 		 * This code path only ever triggers once so we take it
> 		 * out of line.
> 		 */
> 		if ((err = try_to_allocate_compression_buffers())) {
> 			// TODO: do appropriate cleanups
> 			return err;
> 		}
> 	}
> 	disable_preempt();
> 	cb = ntfs_compression_buffers[smp_processor_id()];
> [snip]
> 
> and try_to_allocate_compression_buffers would be:
> 
> int try_to_allocate_compression_buffers(void)
> {
> 	int err = 0;
> 
> 	down(&ntfs_lock);
> 	if (likely(!ntfs_compression_buffers))
> 		err = allocate_compression_buffers();
> 	up(&ntfs_lock);
> 	return err;
> }
> 
> and allocate_compression_buffers() is the same as it is now. Actually I
> was going to fuse try_to_allocate and allocate into one function but as I
> am showing above it is clearer to see what I had in mind...
> 
> Happy now? This basically just defers the allocation to a bit later. As it
> is at the moment the allocation happens at mount time of a partition which
> supports compression. Note that the code in super.c would still need to
> exist due to reference counting so we know when we can free the buffers
> again. The only thing changed in super.c will be to remove the actual call
> to allocate_compression_buffers, all else stays in place. Otherwise we
> have no way to tell when we can throw away the buffers.
> 

I presume allocate_compression_buffers() allocates *all* buffers, and 
doesn't return error if there is nothing to allocate?  If so, the above 
code should be OK.

If allocate_compression_buffers() either doesn't check if it has already 
allocated, or returns an error if buffers were already allocated, then 
the above code is OK *EXCEPT IN THE CASE OF HOTSWAP CPUs*.

My originally proposed code allocated one buffer at a time, and should 
be correct even in the presence of hotswap CPUs.

	-hpa



  reply	other threads:[~2002-06-13  1:38 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
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 [this message]
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=3D07F797.6030007@zytor.com \
    --to=hpa@zytor.com \
    --cc=aia21@mole.bio.cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.