* Re: [PATCH 03/10] AXFS: axfs.h
From: Arnd Bergmann @ 2008-08-21 12:24 UTC (permalink / raw)
To: jaredeh
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <48AD00E6.2070505@gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> +static inline u64 axfs_bytetable_stitch(u8 depth, u8 *table, u64 index)
> +{
> + u64 i;
> + u64 output = 0;
> + u64 byte = 0;
> + u64 j;
> + u64 bits;
> +
> + for (i = 0; i < depth; i++) {
> + j = index * depth + i;
> + bits = 8 * (depth - i - 1);
> + byte = table[j];
> + output += byte << bits;
> + }
> + return output;
> +}
> +
> +#define AXFS_GET_BYTETABLE_VAL(desc,index) \
> + axfs_bytetable_stitch(((struct axfs_region_desc)(desc)).table_byte_depth,\
> + (u8 *)((struct axfs_region_desc)(desc)).virt_addr, index)
> +
This bytetable stuff looks overly complicated, both the data structure and
the access method. It seems like you are implementing your own custom Huffman
compression with this.
Is the reasonn for the bytetable just to pack numbers efficiently, or do you
have a different intention?
Did you see a significant size benefit over simply storing all metadata as
uncompressed data structures like in cramfs?
Have you considered storing simple dentry/inode data in node_type==Compressed
nodes?
Arnd <><
^ permalink raw reply
* Re: [PATCH 10/10] AXFS: axfs_uncompress.c
From: Geert Uytterhoeven @ 2008-08-21 12:28 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: jaredeh, Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <1219318838.18027.68.camel@sauron>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1417 bytes --]
On Thu, 21 Aug 2008, Artem Bityutskiy wrote:
> On Wed, 2008-08-20 at 22:46 -0700, Jared Hulbert wrote:
> > + err = zlib_inflateReset(&stream);
> > + if (err != Z_OK) {
> > + printk(KERN_ERR "zlib_inflateReset error %d\n", err);
> > + zlib_inflateEnd(&stream);
> > + zlib_inflateInit(&stream);
> > + }
>
> just FYI, are you aware that LZO which is also present in the kernel is
> much faster on decompress than zlib, while its compression is only
> slightly worse?
If you want support for multiple decompression algorithms, you can switch
from using zlib_inflate*() directly to calling zlib through the crypto API.
Then you can call crypto_alloc_comp() with the correct decompression algorithm
name.
For squashfs, I had to modify only ca. 40 lines of code.
You do need a new zlib crypto module, as the existing deflate crypto module
uses the raw deflate format instead of the zlib format, and has some parameters
tuned for its use in IPSec.
I hope to have some patches ready next week...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Arnd Bergmann @ 2008-08-21 12:53 UTC (permalink / raw)
To: Nick Piggin
Cc: carsteno, jaredeh, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird
In-Reply-To: <200808212043.51209.nickpiggin@yahoo.com.au>
On Thursday 21 August 2008, Nick Piggin wrote:
> On Thursday 21 August 2008 20:25, Carsten Otte wrote:
> > Jared Hulbert wrote:
> > > I'd like to get a first round of review on my AXFS filesystem.
> >
> > I like the general approach of it. It's much more flexible than the
> > ext2 extension I've done, and the possibility to select XIP vs.
> > compression per page is really really neat. I can imagine that people
> > will prefer this over the ext2 implementation on s390. It is unclear
> > to me how the "secondary block device" thing is supposed to work.
> > Could you elaborate a bit on that?
>
> Agreed. I haven't had a good look through it yet, but at a glance it
> looks pretty neat. The VM side of things looks pretty reasonable
> (I fear XIP faulting might have another race or two, but that's a
> core mm issue rather than filesystem specific).
Yes, I also like the file system, I guess this is 2.6.28 material and
you should have it added to linux-next when you have addressed the
comments so far.
One thing that would be really nice is if you could add fake-write
support in the way that I proposed for cramfs a few months ago.
This would make axfs much more interesting for another set of
users, and keep cramfs a really simple example file system.
Arnd <><
^ permalink raw reply
* Re: [PATCH 03/10] AXFS: axfs.h
From: Daniel Walker @ 2008-08-21 13:10 UTC (permalink / raw)
To: jaredeh
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <48AD00E6.2070505@gmail.com>
On Wed, 2008-08-20 at 22:45 -0700, Jared Hulbert wrote:
> +#define AXFS_GET_BYTETABLE_VAL(desc,index) \
> + axfs_bytetable_stitch(((struct
> axfs_region_desc)(desc)).table_byte_depth,\
> + (u8 *)((struct axfs_region_desc)(desc)).virt_addr, index)
> +
> +#define AXFS_GET_NODE_TYPE(sbi,node_index) \
> + AXFS_GET_BYTETABLE_VAL(((struct axfs_super *)(sbi))->node_type,\
> + (node_index))
> +
> +#define AXFS_GET_NODE_INDEX(sbi,node__index) \
> + AXFS_GET_BYTETABLE_VAL(((struct axfs_super *)(sbi))->node_index,\
> + (node__index))
> +
I think it would be much cleaner to do all these similar macro's as
static inline functions.
Daniel
^ permalink raw reply
* Re: [PATCH 02/10] AXFS: Kconfig and Makefiles
From: Sam Ravnborg @ 2008-08-21 14:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: jaredeh, Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <200808211324.22989.arnd@arndb.de>
On Thu, Aug 21, 2008 at 01:24:22PM +0200, Arnd Bergmann wrote:
> On Thursday 21 August 2008, Jared Hulbert wrote:
> > The Kconfig edits and Makefiles required for AXFS.
> >
> > Signed-off-by: Jared Hulbert <jaredeh@gmail.com>
>
> If you split out this patch separate from the files, please make it the
> *last* patch so that you cannot get build errors during a later git-bisect
> through the middle of your series.
And please use axfs-y := foo.o bar.o
as the old axfs-objs := foo.o bar.o ... syntax is deprecated.
[Replying to this mail as I lost the original]
Thanks,
Sam
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:11 UTC (permalink / raw)
To: Jamie Lokier
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <20080821110749.GA1926@shareable.org>
> How does it fare with no MMU? Can the profiler and image builder lay
> out the XIP pages in such a way that no-MMU mmaps can map those regions?
>
> No complaint if not, it would be a nice bonus though.
Sorry. I don't believe it will work on no-MMU as is. That said you
_could_ tweak the mkfs tool to lay mmap()'ed regions down contiguously
but then if you mmap() an unprofiled region, well that would be bad.
I suppose you could make axfs_mmap smart enough to handle that. I
guess the cleanest way would be to just make files lay down
contiguously, you lose some of the space saving but it would work.
I'm not plannin to get to this anytime soon. But I'd be willing merge
patches. Can anybody convince me offline that working on no-MMU this
makes financial sense for my employer? This is getting to be a common
question. How many noMMU users are out there and why are you so
interested?
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nick Piggin, carsteno, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird
In-Reply-To: <200808211453.26233.arnd@arndb.de>
> One thing that would be really nice is if you could add fake-write
> support in the way that I proposed for cramfs a few months ago.
> This would make axfs much more interesting for another set of
> users, and keep cramfs a really simple example file system.
Did that get merged?
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:13 UTC (permalink / raw)
To: Nick Piggin
Cc: carsteno, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird
In-Reply-To: <200808212043.51209.nickpiggin@yahoo.com.au>
> Agreed. I haven't had a good look through it yet, but at a glance it
> looks pretty neat. The VM side of things looks pretty reasonable
> (I fear XIP faulting might have another race or two, but that's a
> core mm issue rather than filesystem specific).
How might I design a test to flush those bugs out? We haven't seen any.
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Arnd Bergmann @ 2008-08-21 14:14 UTC (permalink / raw)
To: Jared Hulbert
Cc: Nick Piggin, carsteno, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird
In-Reply-To: <6934efce0808210712u36144c78mb7f1998414a549cf@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> > One thing that would be really nice is if you could add fake-write
> > support in the way that I proposed for cramfs a few months ago.
> > This would make axfs much more interesting for another set of
> > users, and keep cramfs a really simple example file system.
>
> Did that get merged?
No, there were a few remaining issues that I never found the time
to work on.
Arnd <><
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:19 UTC (permalink / raw)
To: Jared Hulbert, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel
In-Reply-To: <20080821083916.GF5706@disturbed>
> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
> People are almost certainly going to confuse it with XFS despite
> the filesystems being aimed at diammetrically opposed ends of the
> storage spectrum. ;)
In principle I think you are right. AXFS and XFS are similar names
and it could lead to confusion. I think XFS should change its name to
prevent confusion. I think by 2 years AXFS will be used in orders of
magnitude more machines anyway. ;)
About opposite end of the spectrum... Carsten just said AXFS might be
nice for s390, so I'm not sure how true that is.
I'm kind of attached to the name now.
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:30 UTC (permalink / raw)
To: carsteno
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, nickpiggin
In-Reply-To: <48AD42AE.4030107@de.ibm.com>
> I like the general approach of it. It's much more flexible than the ext2
> extension I've done, and the possibility to select XIP vs. compression per
> page is really really neat. I can imagine that people will prefer this over
> the ext2 implementation on s390. It is unclear to me how the "secondary
> block device" thing is supposed to work. Could you elaborate a bit on that?
First off we don't yet support direct_access(), but I am planning on that soon.
Sure. For a system that has say a NOR Flash and a NAND or a embedded
MMC, one can split a filesystem image such that only the XIP parts of
the image are on the NOR while the compressed bits are on the NAND /
eMMC. The NOR part is accessed as directly addressable memory, while
the NAND would use mtd->read() and the eMMC would use block device
access API's. In this case I would call this NAND or eMMC the
"secondary device" because the primary device is the NOR.
Assuming my NOR was at /dev//mtd2 and my NAND at /dev/mtd5. I would
call the following to mount such a system:
mount -t axfs -o second_dev=/dev/mtd5 /dev/mtd2 /mnt/axfs
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Leon Woestenberg @ 2008-08-21 14:31 UTC (permalink / raw)
To: Jared Hulbert
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <6934efce0808210719s6458dc77w2c0755a4bf90bf8a@mail.gmail.com>
Hello Jared,
On Thu, Aug 21, 2008 at 4:19 PM, Jared Hulbert <jaredeh@gmail.com> wrote:
>> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
>> People are almost certainly going to confuse it with XFS despite
>
People that care about their filesystem choice know their choices.
People that don't
care, well they don't care.
Maybe AXIPFS would be the close alternative.
One question on the use-case profiling and subsequent image rebuild:
What if the use-case did not cover all cases of XIP use?
If a compressed page is attempted to be executed, will the filesystem
fall back to decompression to RAM and execution from RAM, or will this
result in a faulty system?
The design choices look real good. Congrats on the achievement.
Regards,
--
Leon
^ permalink raw reply
* Re: [PATCH 10/10] AXFS: axfs_uncompress.c
From: Jared Hulbert @ 2008-08-21 14:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Artem Bityutskiy, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird, cotte, nickpiggin
In-Reply-To: <Pine.LNX.4.64.0808211423360.20704@vixen.sonytel.be>
> If you want support for multiple decompression algorithms, you can switch
> from using zlib_inflate*() directly to calling zlib through the crypto API.
> Then you can call crypto_alloc_comp() with the correct decompression algorithm
> name.
>
> For squashfs, I had to modify only ca. 40 lines of code.
I definately want to support multiple formats. I have a flag in the
superblock all ready to go for that. One problem. I'm not sure how
to do it. Can you point us to some reference code?
^ permalink raw reply
* Re: [PATCH 10/10] AXFS: axfs_uncompress.c
From: Jared Hulbert @ 2008-08-21 14:37 UTC (permalink / raw)
To: Sven Wegener
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <alpine.LNX.1.10.0808211028150.12259@titan.stealer.net>
> Use DEFINE_MUTEX and drop the mutex_init() down in the init function.
okay. by drop you mean delete?
> axfs_uncompress_init() and axfs_uncompress_exit() are only called during
> init and exit of the module, no need for the initialized variable and the
> functions can be annotated with __init and __exit.
can be annotated or should be?
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-08-21 14:42 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <c384c5ea0808210731k17ccc836u60c4803c3abfea31@mail.gmail.com>
> What if the use-case did not cover all cases of XIP use?
>
> If a compressed page is attempted to be executed, will the filesystem
> fall back to decompression to RAM and execution from RAM, or will this
> result in a faulty system?
No this will not result in a faulty system. It is perfectly
acceptable to have all pages in a file XIP, no pages in a fill XIP,
and anywhere in between.
> The design choices look real good. Congrats on the achievement.
thanks!
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Geert Uytterhoeven @ 2008-08-21 14:49 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Jared Hulbert, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird, cotte, nickpiggin
In-Reply-To: <c384c5ea0808210731k17ccc836u60c4803c3abfea31@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1645 bytes --]
On Thu, 21 Aug 2008, Leon Woestenberg wrote:
> On Thu, Aug 21, 2008 at 4:19 PM, Jared Hulbert <jaredeh@gmail.com> wrote:
> >> FWIW, I'm not sure it's a good idea to name this new filesystem AXFS.
> >> People are almost certainly going to confuse it with XFS despite
> >
> People that care about their filesystem choice know their choices.
> People that don't
> care, well they don't care.
>
> Maybe AXIPFS would be the close alternative.
It seems to be useful for non-XIP, too...
> One question on the use-case profiling and subsequent image rebuild:
>
> What if the use-case did not cover all cases of XIP use?
>
> If a compressed page is attempted to be executed, will the filesystem
> fall back to decompression to RAM and execution from RAM, or will this
> result in a faulty system?
>
> The design choices look real good. Congrats on the achievement.
You probably want to read the paper at
http://ols.fedoraproject.org/OLS/Reprints-2008/hulbert-reprint.pdf
BTW, I regret now not having attended the OLS presentation, because there was
so much emphasis on `XIP' in the description :-)
Fortunately it's been recorded:
http://free-electrons.com/community/videos/conferences/
so I'm gonna watch it right now...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 10/10] AXFS: axfs_uncompress.c
From: Sven Wegener @ 2008-08-21 14:53 UTC (permalink / raw)
To: Jared Hulbert
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <6934efce0808210737w16b5f8dcr1657ea46099e4901@mail.gmail.com>
On Thu, 21 Aug 2008, Jared Hulbert wrote:
> > Use DEFINE_MUTEX and drop the mutex_init() down in the init function.
>
> okay. by drop you mean delete?
Yes.
> > axfs_uncompress_init() and axfs_uncompress_exit() are only called during
> > init and exit of the module, no need for the initialized variable and the
> > functions can be annotated with __init and __exit.
>
> can be annotated or should be?
Should be. We only need them once during init and cleanup. If you want to
call axfs_uncompress_exit() from init_axfs_fs() to clean up in case of
register_filesystem failing, you can't annotate axfs_uncompress_exit()
with __exit.
Sven
^ permalink raw reply
* Re: [PATCH 06/10] AXFS: axfs_super.c
From: Sven Wegener @ 2008-08-21 14:54 UTC (permalink / raw)
To: Jared Hulbert
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <alpine.LNX.1.10.0808211325530.12259@titan.stealer.net>
On Thu, 21 Aug 2008, Sven Wegener wrote:
> On Wed, 20 Aug 2008, Jared Hulbert wrote:
>
> > The many different devices AXFS can mount to and the various
> > dual device mounting schemes are supported here.
> >
> > Signed-off-by: Jared Hulbert <jaredeh@gmail.com>
> > ---
> > +static int __init init_axfs_fs(void)
> > +{
> > + axfs_uncompress_init();
>
> one more thing, axfs_uncompress_init() can fail
>
> > + return register_filesystem(&axfs_fs_type);
And if this fails you leak the memory allocated in axfs_uncompress_init()
> > +}
> > +
> > +static void __exit exit_axfs_fs(void)
> > +{
> > + axfs_uncompress_exit();
> > + unregister_filesystem(&axfs_fs_type);
> > +}
> > +
> > +module_init(init_axfs_fs);
> > +module_exit(exit_axfs_fs);
> > +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 05/10] AXFS: axfs_profiling.c
From: Jared Hulbert @ 2008-08-21 14:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Woodhouse, carsteno, Linux-kernel, linux-embedded,
linux-mtd, Jörn Engel, tim.bird, nickpiggin
In-Reply-To: <200808211339.37187.arnd@arndb.de>
On Thu, Aug 21, 2008 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 21 August 2008, David Woodhouse wrote:
>> On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
>> >
>> > Exporting profiling data for a file system in another file system
>> > (/proc) seems not very straigtforward to me. I think it is worth
>> > considering to export this information via the same mount point.
>>
>> I would have said sysfs, rather than 'the same mount point'.
>>
>
> Let me throw in debugfs as my preferred option. sysfs is for stable
> interfaces, while profiling generally fits into the debugging category.
Three responses, three suggestions....
1) same mount point -
I don't see how this works without an ioctl. I can't just make up
files in my mounted filesystem. You expect the mounted version to
match input to the mkfs. I'd not be happy with an ioctl. You can
just read it.
2) sysfs -
I agree with Carsten, I don't see how this fits in the sysfs hierarchy.
3) debugfs -
I don't know diddly about this.
So why not /proc?
^ permalink raw reply
* Re: [PATCH 05/10] AXFS: axfs_profiling.c
From: Arnd Bergmann @ 2008-08-21 15:06 UTC (permalink / raw)
To: Jared Hulbert
Cc: David Woodhouse, carsteno, Linux-kernel, linux-embedded,
linux-mtd, Jörn Engel
In-Reply-To: <6934efce0808210755n1977e085o63b8b91e84575dc9@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> 1) same mount point -
> I don't see how this works without an ioctl. I can't just make up
> files in my mounted filesystem. You expect the mounted version to
> match input to the mkfs. I'd not be happy with an ioctl. You can
> just read it.
I think what Carsten was suggesting is that you create extra files
in the file system that behave like your current procfs files.
This limits the choice for names inside of the file system, and
therefor I think should not be done.
> 2) sysfs -
> I agree with Carsten, I don't see how this fits in the sysfs hierarchy.
You can create attributes below the device you have mounted.
Technically possible, the main issue I see with this is having
to maintain ABI compatibility.
> 3) debugfs -
> I don't know diddly about this.
>
> So why not /proc?
/proc has the same ABI restrictions as sysfs. We more or less stopped
allowing new files in /proc some 5 years ago for this reason. I didn't
even read beyond the word /proc to know that what you do here is wrong.
debugfs is normally easier to use than procfs as well, you just
define some file_operations with read/write callbacks and call
debugfs_create_file with the path name below /sys/kernel/debug.
If I may give yet another suggestion:
4) no profiling at all
The profiling code has certainly been useful to you during development,
and you should keep that code around for your own work on it,
but maybe you should not push that upstream, because regular users
are not going to need it.
Arnd <><
^ permalink raw reply
* Re: [PATCH 04/10] AXFS: axfs_inode.c
From: Jared Hulbert @ 2008-08-21 15:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <200808211417.14425.arnd@arndb.de>
> Have you seen any benefit of the rwsem over a simple mutex? I would guess
> that you can never even get into the situation where you get concurrent
> readers since I haven't found a single down_read() in your code, only
> downgrade_write()
We implemented a rwsem here because you can get concurrent readers.
My understanding is that downgrade_write() puts the rewem into the
same state as down_read(). Am I mistaken?
^ permalink raw reply
* Re: [PATCH 04/10] AXFS: axfs_inode.c
From: Arnd Bergmann @ 2008-08-21 15:12 UTC (permalink / raw)
To: Jared Hulbert
Cc: Linux-kernel, linux-embedded, linux-mtd, Jörn Engel,
tim.bird, cotte, nickpiggin
In-Reply-To: <6934efce0808210806r701f2e3bo677d2bd2da78faec@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
>
> We implemented a rwsem here because you can get concurrent readers.
> My understanding is that downgrade_write() puts the rewem into the
> same state as down_read(). Â Am I mistaken?
Your interpretation of downgrade_write is correct, but if every thread
always does
down_write();
serialized_code();
downgrade_write();
parallel_code();
up_read();
Then you still won't have any concurrency, because each thread trying
to down_write() will be blocked until the previous one has done its up_read(),
causing parallel_code() to be serialized as well.
In addition to that, I'd still consider it better to use a simple mutex
if parallel_code() is a much faster operation than serialized_code(), as it
is in your case, where only the memcpy is parallel and that is much slower
than the deflate.
Arnd <><
^ permalink raw reply
* Re: [PATCH 05/10] AXFS: axfs_profiling.c
From: Jared Hulbert @ 2008-08-21 15:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Woodhouse, carsteno, Linux-kernel, linux-embedded,
linux-mtd, Jörn Engel
In-Reply-To: <200808211706.37761.arnd@arndb.de>
> /proc has the same ABI restrictions as sysfs. We more or less stopped
> allowing new files in /proc some 5 years ago for this reason. I didn't
> even read beyond the word /proc to know that what you do here is wrong.
> debugfs is normally easier to use than procfs as well, you just
> define some file_operations with read/write callbacks and call
> debugfs_create_file with the path name below /sys/kernel/debug.
no /proc.
thanks for the explanation.
So /sys/kernel/debug/axfs/volume0 would work?
> 4) no profiling at all
> The profiling code has certainly been useful to you during development,
> and you should keep that code around for your own work on it,
> but maybe you should not push that upstream, because regular users
> are not going to need it.
Nope. Profiling is absolutely fundamental to how AXFS works. Read
the [PATCH 00/10] thread again.
^ permalink raw reply
* Re: [PATCH 05/10] AXFS: axfs_profiling.c
From: Geert Uytterhoeven @ 2008-08-21 15:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jared Hulbert, David Woodhouse, carsteno, Linux-kernel,
linux-embedded, linux-mtd, Jörn Engel
In-Reply-To: <200808211706.37761.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 980 bytes --]
On Thu, 21 Aug 2008, Arnd Bergmann wrote:
> On Thursday 21 August 2008, Jared Hulbert wrote:
> 4) no profiling at all
> The profiling code has certainly been useful to you during development,
> and you should keep that code around for your own work on it,
> but maybe you should not push that upstream, because regular users
> are not going to need it.
The profiling is needed to feedback into mkfs.axfs, to decide which pages to
make XIP (in NOR) or not (in NAND). So yes, normal users need it when creating
file systems for a mixed NOR/NAND FLASH system.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 05/10] AXFS: axfs_profiling.c
From: Arnd Bergmann @ 2008-08-21 15:50 UTC (permalink / raw)
To: Jared Hulbert
Cc: David Woodhouse, carsteno, Linux-kernel, linux-embedded,
linux-mtd, Jörn Engel
In-Reply-To: <6934efce0808210817h489bbeafyaf27217ca68bd31e@mail.gmail.com>
On Thursday 21 August 2008, Jared Hulbert wrote:
> So /sys/kernel/debug/axfs/volume0 would work?
>
> > 4) no profiling at all
> > The profiling code has certainly been useful to you during development,
> > and you should keep that code around for your own work on it,
> > but maybe you should not push that upstream, because regular users
> > are not going to need it.
>
> Nope. Profiling is absolutely fundamental to how AXFS works. Read
> the [PATCH 00/10] thread again.
Ok, understood it now. So it actually is a stable interface into
the file system, which means that debugfs might not be the best
solution.
I need to think about this some more. So far none of the options
are perfect. What I can think of so far includes:
1. An ioctl on the mount point of the fs
2. An ioctl that you need to call on each file
3. sysfs files is /sys/fs/axfs/
4. A new virtual file system to be mounted to /sys/fs/axfs/
5. A file below the device in sysfs, e.g. /sys/block/mtdblk0/axfs-profile
I've also taken a look at the format of the profiling data file.
I'm not sure that it is ideal if you want to be able to share
identical data blocks between files. Do you currently do that
in your mkfs? The fs format certainly allows it. I would expect
that if you checksum each page, you can find duplicates on a page
basis and save some space this way. However, it can make profiling
harder if you count based on blocks but report the data based on
the file name. Not sure what a better solution would look like.
Arnd <><
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox