lkml.org 
[lkml]   [2010]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: atomic RAM ?
On Thu, Apr 8, 2010 at 03:32, Michael Schnell wrote:
>  - new "custom" processor instructions can be defined that might work
> atomically, as well not interruptible as kind of bus-locking for SMP use
>  - these custom instructions can't access the memory in normal way
> (through the MMU and the cache).
>
> So to implement atomic instructions a dedicated RAM area would be needed
> to hold the atomically accessible data. Same can't be accessed by the
> CPU in other ways. This RAM area would be implemented with the new
> atomic instructions and be located within the FPGA and thus could
> accessed very fast (no cache issues).
>
> Of course this would need for the Kernel and the libraries to avoid any
> access to that RAM area with normal instructions. All code would need to
> use the set of "atomic" macros to access that RAM. Here I suppose we
> would need some additional atomic Macros such as "atomic_malloc()",
> "atomic_read_word()" etc, which, with normal archs would just reproduce
> the standard code.
>
> Of course the size of the "atomic RAM" would be limited and thus a
> system error would be generated if same would be exhausted. I don't
> think that, with the intended "embedded" use, this would be a serious issue.
>
> I feel that thinking about this could be viable task - even if this
> might ask for some modifications in the global arch-independent Kernel
> and/or library code, as I suppose this is the only way to allow for
> implementing an SMP design with NIOS and similar archs. (Happily these
> modifications would be "compatible" by design as with any existing arch
> just the existing code would be reproduced by the new Macros and so
> their use is strictly optional with any arch other than those that would
> profit from the new implementation.)

the Blackfin already has such an instruction (TESTSET), but since it
has restrictions (cannot be used safely on cached memory), we found it
unusable as a generic solution. this is why we went to the userspace
fixed atomic code region.

the only time we use this instruction is with the Blackfin SMP port,
and only as an inter-core lock (so it has a fixed address and there is
only one such lock).

i think you underestimate the task of customizing every userspace
point that may want atomic instructions. and no matter what sized
atomic region you pick, having it arbitrarily fail at runtime because
applications have "too many" locks is a poor solution.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-04-09 03:39    [W:0.118 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site