On Sat, Apr 24, 2010 at 10:43 AM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > Greg Freemyer wrote: >> On Sat, Apr 24, 2010 at 9:48 AM, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote: >>> On 04/24/2010 09:24 AM, Greg Freemyer wrote: > > ... > >>>> I know I've been arguing against this patch for the single SSD case >>>> and I still think that use case should be handled by userspace as >>>> hdparm/wiper.sh currently does. In particular for those extreme >>>> scenarios with JBOD SSDs, the user space solution wins because it >>>> knows how to optimize the trim calls via vectorized ranges in the >>>> payload. >>>> >>> I think that you have missed the broader point. This is not on by default, >>> so you can mount without discard and use whatever user space utility you >>> like at your discretion. >>> >>> ric >> >> Ric, >> >> I was trying to say the design should be driven by the large discard >> range use case, not the potentially pathological small discard range >> use case that would only benefit SSDs. >> >> Greg > > Bear in mind that this patch makes the discard range requests substantially > -larger- than what mount -o discard does on ext4 today, in fact that was > a main goal. > > If the kernel could assemble vectors of ranges and pass them down, I think it > could be extended to use that as well. > > -Eric > Eric/Ric, I was responding to the Lukas latest post which stated: == And also, currently I am rewriting the patch do use rbtree instead of the bitmap, because there were some concerns of memory consumption. It is a question whether or not the rbtree will be more memory friendly. Generally I think that in most "normal" cases it will, but there are some extreme scenarios, where the rbtree will be much worse. Any comment on this ? == If one optimizes for large discard ranges and ignores the pathological cases only beneficial to SSDs, then a rbtree wins. Correct? Greg -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
