On Tuesday 08 March 2011, Pavel Machek wrote:
> > >
> > > How big is performance difference?
> >
> > Several orders of magnitude. It is very easy to get a card that can write
> > 12 MB/s into a case where it writes no more than 30 KB/s, doing only
> > things that happen frequently with ext3.
>
>
On Wed, Mar 2, 2011 at 4:34 AM, Andrei Warkentin wrote:
> Before the generic improvements are made to the block layer, I think
> there is some value
> in implementing the (simpler) ones in mmc block code, as well as
> expose an mmc block quirk interface by which its easy to add complex
> workaroun
On Tue, Mar 1, 2011 at 1:11 PM, Arnd Bergmann wrote:
> On Tuesday 01 March 2011 19:48:17 Jens Axboe wrote:
>>
>> On 2011-02-25 07:21, Arnd Bergmann wrote:
>> > On Friday 25 February 2011, Andrei Warkentin wrote:
>> >> Yup. I understand :-). That's the strategy I'm going to follow. For
>> >> page_
On Tue, Mar 1, 2011 at 1:51 PM, Arnd Bergmann wrote:
> On Tuesday 01 March 2011 20:15:30 Jens Axboe wrote:
>> Thanks for the recap. One way to handle this would be to have a dm
>> target that ensures that requests are never built up to violate any of
>> the above items. Doing splitting is a little
On Tuesday 01 March 2011 20:15:30 Jens Axboe wrote:
> Thanks for the recap. One way to handle this would be to have a dm
> target that ensures that requests are never built up to violate any of
> the above items. Doing splitting is a little silly, when you can prevent
> it from happening in the fir
On 2011-03-01 14:11, Arnd Bergmann wrote:
> On Tuesday 01 March 2011 19:48:17 Jens Axboe wrote:
>>
>> On 2011-02-25 07:21, Arnd Bergmann wrote:
>>> On Friday 25 February 2011, Andrei Warkentin wrote:
Yup. I understand :-). That's the strategy I'm going to follow. For
page_size-alignment/
On Tuesday 01 March 2011 19:48:17 Jens Axboe wrote:
>
> On 2011-02-25 07:21, Arnd Bergmann wrote:
> > On Friday 25 February 2011, Andrei Warkentin wrote:
> >> Yup. I understand :-). That's the strategy I'm going to follow. For
> >> page_size-alignment/splitting I'm looking at the block layer now.
On 2011-02-25 07:21, Arnd Bergmann wrote:
> On Friday 25 February 2011, Andrei Warkentin wrote:
>> Yup. I understand :-). That's the strategy I'm going to follow. For
>> page_size-alignment/splitting I'm looking at the block layer now. Is
>> that the right approach or should I still submit a (clea
On Friday 25 February 2011, Andrei Warkentin wrote:
> Yup. I understand :-). That's the strategy I'm going to follow. For
> page_size-alignment/splitting I'm looking at the block layer now. Is
> that the right approach or should I still submit a (cleaned up) patch
> to mmc/card/block.c for that pe
On Thu, Feb 24, 2011 at 3:24 AM, Arnd Bergmann wrote:
> Unlike the sysfs interface, the code does not need to be future-proof,
> it can always be changed if we feel the code becomes more maintainable
> by doing it another way.
>
> The approach that I'd like to see here is:
>
> * Start out with an
On Wednesday 23 February 2011, Andrei Warkentin wrote:
> I am more concerned with workarounds that depend on access size (like
> the toshiba one) and that modify the MMC commands sent (using reliable
> writes, like the Toshiba one, or putting parameters differently like
> the Sandisk erase workaro
On Wed, Feb 23, 2011 at 10:09 AM, Arnd Bergmann wrote:
> On Wednesday 23 February 2011, Andrei Warkentin wrote:
>> That sounds good! In fact, for any quirks enabled for a particular
>> card, I'll expose the tuneables through sysfs attributes, something
>> like /sys/block/mmcblk0/device/quirks/quir
On Wednesday 23 February 2011, Andrei Warkentin wrote:
> That sounds good! In fact, for any quirks enabled for a particular
> card, I'll expose the tuneables through sysfs attributes, something
> like /sys/block/mmcblk0/device/quirks/quirk-name/attr-names.
>
> Quirks will have block intervals and
On Tue, Feb 22, 2011 at 11:00 AM, Arnd Bergmann wrote:
>>
>> Do you think there is any need for runtime tuning of the MMC
>> workarounds (disregarding ones that really belong in the I/O
>> scheduler)? Should the workarounds be simply platform callbacks, or
>> should they be something heftier ("pol
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 8:39 AM, Arnd Bergmann wrote:
> > E.g. the I/O scheduler can also make sure that we always submit all
> > blocks from the start of one erase unit (e.g. 4 MB) to the end, but
> > not try to merge requests across erase un
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann wrote:
> > The description of the test case is probably suboptimal. What this does
> > is 32 KB accesses, with 32 KB alignment in the pre and post case, but 16 KB
> > alignment in the "on" case. T
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 9:03 AM, Arnd Bergmann wrote:
> >
> > From your flashbench -a run, I would guess that it uses
> > 8 MB allocation units, although the data is not 100% conclusive
> > there.
> >
>
> Because the 8MB aligned write time is
On Sun, Feb 20, 2011 at 8:39 AM, Arnd Bergmann wrote:
> [adding linux-fsdevel to Cc, see http://lwn.net/Articles/428941/ and
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/105607 for more
> on this discussion.]
>
>
> I think it's good to discuss all the options, but my feeling is that
>
On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann wrote:
> The description of the test case is probably suboptimal. What this does
> is 32 KB accesses, with 32 KB alignment in the pre and post case, but 16 KB
> alignment in the "on" case. The idea here is that it should never do
> any access with les
On Sunday 20 February 2011 06:56:39 Andrei Warkentin wrote:
> On Sat, Feb 19, 2011 at 5:20 AM, Arnd Bergmann wrote:
> > The numbers you see here are taken over multiple runs. Do you see a lot
> > of fluctuation when doing this with --count=1?
> >
>
> Yep. Quite a bit.
>
> # ./flashbench -c 1 -A
On Sunday 20 February 2011 05:39:06 Andrei Warkentin wrote:
> Actually it would be a good idea to also bail/warn if you do the au
> test with more open au's than the size of the passed device allows,
> since it'll just wrap around and skew the results.
Yes, that's a bug. I never noticed because al
[adding linux-fsdevel to Cc, see http://lwn.net/Articles/428941/ and
http://comments.gmane.org/gmane.linux.ports.arm.kernel/105607 for more
on this discussion.]
On Sunday 20 February 2011 12:27:39 Andrei Warkentin wrote:
> On Thu, Feb 17, 2011 at 9:47 AM, Arnd Bergmann wrote:
> > I think I'd try
On Thu, Feb 17, 2011 at 9:47 AM, Arnd Bergmann wrote:
> I think I'd try to reduce the number of sysfs files needed for this.
> What are the values you would typically set here?
>
> My feeling is that separating unaligned page writes from full pages
> or multiples of pages could always be benefitia
On Sat, Feb 19, 2011 at 5:20 AM, Arnd Bergmann wrote:
> On Saturday 19 February 2011 00:17:51 Andrei Warkentin wrote:
>> # echo 0 > /sys/block/mmcblk0/device/page_size
>> # ./flashbench -A -b 1024 /dev/block/mmcblk0p9
>> write align 8388608 pre 3.59ms on 6.54ms post 3.65ms diff
On Sat, Feb 19, 2011 at 3:54 AM, Arnd Bergmann wrote:
> On Friday 18 February 2011 23:40:16 Andrei Warkentin wrote:
>> On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin
>> wrote:
>>
>> Flashbench timings for both Sandisk and Toshiba cards. Attaching due to size.
>
> Very nice, thanks for the mea
On Saturday 19 February 2011 00:17:51 Andrei Warkentin wrote:
> # echo 0 > /sys/block/mmcblk0/device/page_size
> # ./flashbench -A -b 1024 /dev/block/mmcblk0p9
> write align 8388608 pre 3.59ms on 6.54ms post 3.65ms diff
> 2.92ms
> write align 4194304 pre 4.13ms on 7.37m
On Friday 18 February 2011 23:40:16 Andrei Warkentin wrote:
> On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin
> wrote:
>
> Flashbench timings for both Sandisk and Toshiba cards. Attaching due to size.
Very nice, thanks for the measurement!
I don't think having the results inline in the mail i
2011/2/18 Andrei Warkentin :
> On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin
> wrote:
>> On Fri, Feb 18, 2011 at 7:44 AM, Arnd Bergmann wrote:
>>> I'm curious. Neither the manfid nor the oemid fields of either card
>>> match what I have seen on SD cards, I would expect them to be
>>>
>>> San
On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin wrote:
> On Fri, Feb 18, 2011 at 7:44 AM, Arnd Bergmann wrote:
>> I'm curious. Neither the manfid nor the oemid fields of either card
>> match what I have seen on SD cards, I would expect them to be
>>
>> Sandisk: manfid 0x03, oemid 0x5344
>>
On Fri, Feb 18, 2011 at 7:44 AM, Arnd Bergmann wrote:
> I'm curious. Neither the manfid nor the oemid fields of either card
> match what I have seen on SD cards, I would expect them to be
>
> Sandisk: manfid 0x03, oemid 0x5344
> Toshiba: manfid 0x02, oemid 0x544d
>
> I have not actually se
On Friday 18 February 2011, Andrei Warkentin wrote:
> On Fri, Feb 11, 2011 at 4:33 PM, Andrei Warkentin
> wrote:
> > Arnd,
> >
> > Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
> >
> > cid - 02010053454d3332479070cc51451d00
> > csd - d00f00320f5903ff92404000
On Fri, Feb 11, 2011 at 4:33 PM, Andrei Warkentin wrote:
> Arnd,
>
> Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
>
> cid - 02010053454d3332479070cc51451d00
> csd - d00f00320f5903ff92404000
> erase_size - 524288
> fwrev - 0x0
> hwrev - 0x0
> manfid - 0x0
On Thursday 17 February 2011, Andrei Warkentin wrote:
> Ext4.
Ok, I see. I haven't really done this kind of tests before, but my
feeling is that ext3/ext4 may be much worse than the alternatives
at the moment. It would certainly be worthwhile to do tests using
nilfs2 and btrfs, whose default behav
On Tue, Feb 15, 2011 at 11:16 AM, Arnd Bergmann wrote:
> On Monday 14 February 2011, Andrei Warkentin wrote:
>> > There are multiple ways how this could be implemented:
>> >
>> > 1. Have one exception cache for all "special" blocks. This would normally
>> > be for FAT32 subdirectory updates, whi
On Monday 14 February 2011, Andrei Warkentin wrote:
> > There are multiple ways how this could be implemented:
> >
> > 1. Have one exception cache for all "special" blocks. This would normally
> > be for FAT32 subdirectory updates, which always write to the same
> > few blocks. This means you c
On Mon, Feb 14, 2011 at 2:22 PM, Arnd Bergmann wrote:
>>
>> As I mentioned, I am checking with T right now on whether we can use
>> suggestion (1) or
>> suggestion (2) or if they need to be combined. The documentation we
>> got was open to interpretation and the patch created from that did
>> both
On Monday 14 February 2011 20:29:59 Andrei Warkentin wrote:
> On Sun, Feb 13, 2011 at 11:39 AM, Arnd Bergmann wrote:
>
> Ah sorry, I had to look that one up myself, I thought it was the local
> jargon associated with the problem space :-). Program/Erase cycle.
Ok, makes sense.
> >> So T suggeste
On Sun, Feb 13, 2011 at 11:39 AM, Arnd Bergmann wrote:
> I don't think it needs to be boot-time, it can easily be run-time
> tuneable using sysfs, where you can configure it using an init script
> or some other logic from user space.
True, definitely expose the controls through sysfs.
>
> Yes.
On Sunday 13 February 2011 01:10:09 Andrei Warkentin wrote:
> On Sat, Feb 12, 2011 at 12:37 PM, Arnd Bergmann wrote:
>
> > This part might make sense in general, though it's hard to know the
> > page size in the general case. For many SD cards, writing naturally
> > aligned 64 KB blocks was the id
On Sat, Feb 12, 2011 at 12:37 PM, Arnd Bergmann wrote:
> On Friday 11 February 2011 23:27:51 Andrei Warkentin wrote:
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index 7054fd5..3b32329 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -31
On Friday 11 February 2011 23:27:51 Andrei Warkentin wrote:
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 7054fd5..3b32329 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -312,6 +316,157 @@ out:
> return err ? 0 : 1;
> }
>
> +/
On Saturday 12 February 2011 18:33:10 Andrei Warkentin wrote:
> On Sat, Feb 12, 2011 at 11:05 AM, Arnd Bergmann wrote:
> > On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
> >> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
> >
> >> Yes, this is a Toshiba card. I've sent the patc
On Sat, Feb 12, 2011 at 11:05 AM, Arnd Bergmann wrote:
> On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
>> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
>
>> Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
>>
>> cid - 02010053454d3332479070cc51451d
On Friday 11 February 2011 23:33:42 Andrei Warkentin wrote:
> On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
> Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
>
> cid - 02010053454d3332479070cc51451d00
> csd - d00f00320f5903ff92404000
> erase_size - 524
On Sat, Feb 12, 2011 at 05:28:32PM +0100, Arnd Bergmann wrote:
> On Saturday 12 February 2011 11:59:18 Russell King - ARM Linux wrote:
> > Unrelated, I have a USB based device which provides an emulated FAT
> > filesystem - all files except one on this filesystem are read-only.
> > The writable fil
On Saturday 12 February 2011 11:59:18 Russell King - ARM Linux wrote:
> On Sat, Feb 12, 2011 at 11:45:41AM +0100, Arnd Bergmann wrote:
> > * The FAT location is clearly visible in a number of tests
> > done inside of an allocation unit. It's normally slower for
> > linear access, but faster for
On Sat, Feb 12, 2011 at 11:45:41AM +0100, Arnd Bergmann wrote:
> * The FAT location is clearly visible in a number of tests
> done inside of an allocation unit. It's normally slower for
> linear access, but faster for random access. Sometimes
> reading the FAT is also slower than reading else
On Saturday 12 February 2011 00:23:37 Linus Walleij wrote:
> H'm! That's an interesting resource indeed. When you write
> "From measurements, it appears that the size in which data is
> managed is typically 64 kb on SD cards" and "the size of the
> medium is always a multiple of entire allocation g
On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann wrote:
> On Wednesday 09 February 2011 09:37:40 Linus Walleij wrote:
>> [Quoting in verbatin so the orginal mail hits linux-mmc, this is very
>> interesting!]
>>
>> 2011/2/8 Andrei Warkentin :
>> > Hi,
>> >
>> > I'm not sure if this is the best place t
2011/2/9 Arnd Bergmann :
> Most of my results so far are documented on
> https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
H'm! That's an interesting resource indeed. When you write
"From measurements, it appears that the size in which data is
managed is typically
On Wed, Feb 9, 2011 at 2:37 AM, Linus Walleij wrote:
> [Quoting in verbatin so the orginal mail hits linux-mmc, this is very
> interesting!]
>
> 2011/2/8 Andrei Warkentin :
>> Hi,
>>
>> I'm not sure if this is the best place to bring this up, but Russel's
>> name is on a fair share of drivers/mmc
On Wednesday 09 February 2011 09:37:40 Linus Walleij wrote:
> [Quoting in verbatin so the orginal mail hits linux-mmc, this is very
> interesting!]
>
> 2011/2/8 Andrei Warkentin :
> > Hi,
> >
> > I'm not sure if this is the best place to bring this up, but Russel's
> > name is on a fair share of d
[Quoting in verbatin so the orginal mail hits linux-mmc, this is very
interesting!]
2011/2/8 Andrei Warkentin :
> Hi,
>
> I'm not sure if this is the best place to bring this up, but Russel's
> name is on a fair share of drivers/mmc code, and there does seem to be
> quite a bit of MMC-related disc
On Tue, Feb 08, 2011 at 03:22:59PM -0600, Andrei Warkentin wrote:
> Hi,
>
> I'm not sure if this is the best place to bring this up, but Russel's
> name is on a fair share of drivers/mmc code, and there does seem to be
> quite a bit of MMC-related discussions. Excuse me in advance if this
> isn't
54 matches
Mail list logo
