On Tue, Feb 2, 2016 at 4:34 PM, Matthew Wilcox wrote:
> On Tue, Feb 02, 2016 at 01:46:06PM -0800, Jared Hulbert wrote:
>> On Tue, Feb 2, 2016 at 8:51 AM, Dan Williams
>> wrote:
>> >> The filesystem I'm concerned with is AXFS
>> >> (https://www.kernel.
On Tue, Feb 2, 2016 at 3:41 PM, Dan Williams wrote:
> On Tue, Feb 2, 2016 at 3:36 PM, Jared Hulbert wrote:
>> On Tue, Feb 2, 2016 at 3:19 PM, Al Viro wrote:
>>>
>>> On Tue, Feb 02, 2016 at 04:11:42PM -0700, Ross Zwisler wrote:
>>>
>>> > Howeve
On Tue, Feb 2, 2016 at 3:19 PM, Al Viro wrote:
>
> On Tue, Feb 02, 2016 at 04:11:42PM -0700, Ross Zwisler wrote:
>
> > However, for raw block devices and for XFS with a real-time device, the
> > value in inode->i_sb->s_bdev is not correct. With the code as it is
> > currently written, an fsync or
On Tue, Feb 2, 2016 at 8:51 AM, Dan Williams wrote:
> On Tue, Feb 2, 2016 at 12:05 AM, Jared Hulbert wrote:
> [..]
>> Well... as CONFIG_BLOCK was not required with filemap_xip.c for a
>> decade. This CONFIG_BLOCK dependency is a result of an incremental
>> feature from
On Mon, Feb 1, 2016 at 10:46 PM, Dan Williams wrote:
> On Mon, Feb 1, 2016 at 10:06 PM, Jared Hulbert wrote:
>> On Mon, Feb 1, 2016 at 1:47 PM, Dave Chinner wrote:
>>> On Mon, Feb 01, 2016 at 03:51:47PM +0100, Jan Kara wrote:
>>>> On Sat 30-01-16 00:28:33, Matth
On Mon, Feb 1, 2016 at 1:47 PM, Dave Chinner wrote:
> On Mon, Feb 01, 2016 at 03:51:47PM +0100, Jan Kara wrote:
>> On Sat 30-01-16 00:28:33, Matthew Wilcox wrote:
>> > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote:
>> > > I guess I need to go off and understand if we can have DAX ma
On Fri, Jan 29, 2016 at 10:01 PM, Dan Williams wrote:
> On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox wrote:
>> On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote:
>>> I guess I need to go off and understand if we can have DAX mappings on such
>>> a
>>> device. If we can, we may hav
On Mon, Jan 25, 2016 at 1:18 PM, Jared Hulbert wrote:
> On Mon, Jan 25, 2016 at 8:52 AM, Matthew Wilcox wrote:
>> On Sun, Jan 24, 2016 at 01:03:49AM -0800, Jared Hulbert wrote:
>>> I our defense we didn't know we were sinning at the time.
>>
>> Fair enough.
On Mon, Jan 25, 2016 at 8:52 AM, Matthew Wilcox wrote:
> On Sun, Jan 24, 2016 at 01:03:49AM -0800, Jared Hulbert wrote:
>> I our defense we didn't know we were sinning at the time.
>
> Fair enough. Cache flushing is Hard.
>
>> Can you walk me through the cache flus
I our defense we didn't know we were sinning at the time.
Can you walk me through the cache flushing hole? How is it okay on
X86 but not VIVT archs? I'm missing something obvious here.
I thought earlier that vm_insert_mixed() handled the necessary
flushing. Is that even the part you are worrie
HI! I've been out of the community for a while, but I'm trying to
step back in here and catch up with some of my old areas of specialty.
Couple questions, sorry to drag up such old conversations.
The DAX documentation that made it into kernel 4.0 has the following
line "The DAX code does not wor
> > I think so. The filemap_xip.c functionality doesn't work for Flash
> > memory yet. Flash memory doesn't have struct pages to back it up with
> > which this stuff depends on.
>
> Struct page is not the major issue. The primary problem is writing to
> the media (and I am not a flash expert at a
> Um, trying to clarify: S390. Also known as zSeries, big iron machine, uses
> its own weird processor design rather than x86, x86-64, arm, or mips
> processors.
Right. filemap_xip.c allows for an XIP filesystem. The only
filesystem that is supported is ext2. Even that requires a block
device
> > I have'nt looked at it yet. I do appreciate it, I think it might
> > broaden the user-base of this feature which is up to now s390 only due
> > to the fact that the flash memory extensions have not been implemented
> > (yet?). And it enables testing xip on other platforms. The patch is on
> > m
> Probably about 1000 clocks but its always going to depend upon the
> workload and whether any other work can be done usefully.
Yeah. Sounds right, in the microsecond range. Be interesting to see data.
Anybody have ideas on what kind of experiments could confirm this
estimate is right?
--
To u
On Dec 4, 2007 3:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Right. The trend is to hide the nastiness of NAND technology changes
> > behind controllers. In general I think this is a good thing.
>
> You miss the point - any controller you hide it behind almost inevitably
> adds enough latency
> > Maybe I'm missing something but I don't see it. We want a block
> > interface for these devices, we just need a faster slimmer interface.
> > Maybe a new mtdblock interface that doesn't do erase would be the
> > place for?
>
> Doesn't do erase? MTD has to learn almost all tricks from the bloc
> > microseconds level and an order of magnitude higher bandwidth than
> > SATA. Is that fast enough to warrant this more synchronous IO?
>
> See the mtd layer.
Right. The trend is to hide the nastiness of NAND technology changes
behind controllers. In general I think this is a good thing.
Basi
> > refinements could theoretically get us down one more (~100
> > microsecond).
>
> They've already done already better than that. Here's a solid state
> drive with a claimed 20 microsecond access time:
>
> http://www.curtisssd.com/products/drives/hyperxclr
Right. That looks to be RAM based, wh
> > Has anyone played with this concept?
>
> For things like SATA based devices they aren't that fast yet.
What is fast enough?
As I understand the basic memory technology, the hard limit is in the
100's of microseconds range for latency. SATA adds something to that.
I'd be surprised to see lat
> > I think that this idea is not worth it.
Don't use the config option then
> My problem is that switching off printk is the single biggest bloat cutter in
> the kernel, yet it makes the resulting system very hard to support. It
> combines a big upside with a big downside, and I'd like some
Recently there has been some discussion of the possiblity of reworking
some of filemap_xip.c to be pfn oriented. This would allow an XIP
fork of cramfs to use the filemap_xip framework. Today this is not
possible.
I've been trying out vm_insert_pfn() to start down that road. I used
spufs as a
On 7/2/07, Jörn Engel <[EMAIL PROTECTED]> wrote:
On Mon, 2 July 2007 10:44:00 -0700, Jared Hulbert wrote:
>
> >So what you mean is "swap on flash" ? Defintively sounds like an
> >interesting topic, although I'm not too sure it's all that
> >filesy
So what you mean is "swap on flash" ? Defintively sounds like an
interesting topic, although I'm not too sure it's all that
filesystem-related.
Maybe not. Yet, it would be a very useful place to store data from a
file as a non-volatile page cache.
Also it is something that I believe would bene
> Christoph> So what you mean is "swap on flash" ? Defintively sounds
> Christoph> like an interesting topic, although I'm not too sure it's
> Christoph> all that filesystem-related.
I wouldn't want to call it swap, as this carries with it block-io
connotations. It's really mmap on flash.
Yes
On 6/25/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Mon, Jun 25, 2007 at 05:08:02PM -0700, Jared Hulbert wrote:
> -memory mappable swap file (I'm not sure if this one is appropriate
> for the proposed meeting)
Please explain what this is supposed to mean.
If you have
A few things I'd like to talk about are:
- the address space operations APIs, and their page based nature. I think
it would be nice to generally move toward offset,length based ones as
much as possible because it should give more efficiency and flexibility
in the filesystem.
- write_begin
On 6/15/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
Nick Piggin wrote:
> Carsten Otte wrote:
>> The current xip stack relies on having struct page behind the memory
>> segment. This causes few impact on memory management, but occupies
>> some more memory. The cramfs patch chose to modify copy on
If you can write code that doesn't need any struct pages that would make
life a bit easier, since we wouldn't need any pseudo memory hotplug code
that just adds struct pages.
That was my gut feel too. However, it seems from Carsten and Jörn
discussion of read/write XIP on Flash (and some new Ph
An alternative approach, which does not need to have struct page at
hand, would be to use the nopfn vm operations struct. That one would
have to rely on get_xip_pfn.
Of course! Okay now I'm begining to understand.
The current path would then be deprecated.
Why? Wouldn't both paths be valid
Nick Piggin wrote:
> The question is, why is that not enough (I haven't looked at these
> patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
The downside: We need mem_map[] struct page entries behind all memory
segments. Nowerdays we can easily create those via vmem_map/sparsemem.
Opinions?
Frankly this is going to be mostly relevant on ARM architectures at
least at first. Maybe I'm missing something but I don't see that
sparemem i
On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> Okay so we need some driver that opens/closes this ROM. This has been
> done from the dcss block device but that doesn't make sense for most
> embedded systems. The MTD allows for this with point(),unpoint().
>
On 6/8/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Fri, Jun 08, 2007 at 09:59:20AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >Jared's patch currently does ioremap on mount (and no iounmap at all).
> >That mapping needs to move from the filesystem to the device driver.
> The
On 6/8/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 01:34:12PM -0700, Jared Hulbert wrote:
> >And we'll need that even when using cramfs. There's not way we'd
> >merge a hack where the user has to specify a physical address on
>
I am trying to create valid "struct page* (*get_xip_page)(struct
address_space *, sector_t, int)" to use the filemap_xip.c.
I've been trying to do it as follows:
virtual = ioremap(physical,size);
struct page* my_get_xip_page(struct address_space *mapping, sector_t
sector, int create)
{
unsigne
If if were actually talking about complex filesystem I'd agree. But
the cramfs xip patch posted here touches about 2/3 of the number of
lines that cramfs has in total.
Fair enough. But look at the complexity rather than number of lines.
It adds tedium to the cramfs_fill_super and one extra lev
I've had a few beer long discussion with Joern Engel and David
Woodhouse on this one. To cut a long discussion short: the current XIP
infrastructure is not sufficient to be used on top of mtd. We'd need
some extenstions:
- on get_xip_page() we'd need to state if we want the reference
read-only or
that even more important doesn't require pulling in
the whole block layer which is especially important for embedded
devices at the lower end of the scala.
Good point. That is a big oversight. Though I would prefer to handle
that in the same fs rather than fork.
I still think it'd be even be
On 6/7/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
> I've had a few beer long discussion with Joern Engel and David
> Woodhouse on this one. To cut a long discussion short: the current XIP
> infrastructure is not sufficient to be
On 6/7/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 08:37:07PM +0100, Christoph Hellwig wrote:
> The code is at http://verein.lst.de/~hch/cramfs-xip.tar.gz.
And for thus just wanting to take a quick glance, this is the
diff vs an out of tree cramfs where uncompress.c
On 6/6/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
Jared Hulbert wrote:
> (2) failed with the following messages. (This wasn't really busybox.
> It was xxd, not statically link, hence the issue with ld.so)
Could you try to figure what happend to subject page before? Was it
s
The embedded people already use them
on flash which is a little dumb, but now we add even more cludge for
a non-block based access.
Please justify your assertion that using cramfs on flash is dumb.
What would be not dumb? In an embedded system with addressable Flash
the linear addressing cramf
On Wed, Jun 06, 2007 at 09:07:16AM -0700, Jared Hulbert wrote:
> I estimate something on the order 5-10 million Linux phones use
> something similar to these patches. I wonder if there are that many
> provable users of of the simple cramfs. This is where the community
> has taken c
On 6/6/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Wed, Jun 06, 2007 at 08:17:43AM -0700, Richard Griffiths wrote:
> Too late :) The XIP cramfs patch is widely used in the embedded Linux
> community and has been used for years. It fulfills a need for a small
> XIP Flash file system. Hence
On 6/6/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
I might be a little late in the discussion, but I somehow missed this
before. Please don't add this xip support to cramfs, because the
whole point of cramfs is to be a simple _compressed_ filesystem,
and we really don't want to add more com
icense
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/* filemap_xip.c interfaces - Jared Hulbert 2007
+ * linear + block coexisting - Jared Hulbert 2007
+ * (inspired by patches from Kyungmin Park of
> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So far, Hugh and Linus h
Yes you can, but I won't have access to a PXA270 for a few weeks. I
assume you don't see the issue if you static link busybox?
I don't know.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
On 5/22/07, Richard Griffiths <[EMAIL PROTECTED]> wrote:
Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
the embedded Linux community for years, updated for 2.6.21. Tested on
several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
Freescale iMX31ADS.
Whe
To me, it looks like this
work can be modified to use filemap_xip.
How?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tu
51 matches
Mail list logo
