Hi,
Jianjian, You really get a point at the fundamental design.
> If I understand it correctly, the whole idea indeed is very simple,
> the consumer/provider and circular buffer model. use SSD as a circular
> write buffer, write flush thread stores incoming writes to this buffer
> sequentially as
> >>> Don't hide "implementation of locks" in functions like this, it only
> >>> causes problems. This code has layers of layers of layers of
> >>> abstractions due to it wanting to be originally ported to other
> >>> operating systems and lots of different kernel versions of Linux itself.
> >>> U
Hello,
The convention for checking for NULL pointers is !ptr and not ptr == NULL.
This patch fixes such occurences in goldfish driver, it applies against
next-20141212
Signed-off-by: Loic Pefferkorn
---
drivers/staging/goldfish/goldfish_audio.c | 8
drivers/staging/goldfish/goldfish
Loic,
On Sat, Dec 13, 2014 at 05:29:26PM +0100, Loic Pefferkorn wrote:
> Hello,
>
> The convention for checking for NULL pointers is !ptr and not ptr == NULL.
> This patch fixes such occurences in goldfish driver, it applies against
> next-20141212
>
Whose convention is this? I can't find any
> Whose convention is this? I can't find any mention in
> Documention/CodingStyle. checkpatch.pl doesn't complain about them.
> And there are almost three thousand examples in staging which don't
> use this convention.
>
> linux-next$ grep -r "== NULL" drivers/staging/* | wc -l
> 2844
Hi Jer
On Sat, 13 Dec 2014 17:29:26 +0100
Loic Pefferkorn wrote:
> Hello,
>
> The convention for checking for NULL pointers is !ptr and not ptr == NULL.
> This patch fixes such occurences in goldfish driver, it applies against
> next-20141212
>
>
> Signed-off-by: Loic Pefferkorn
Pointless churn. I
Loïc,
On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote:
> > Whose convention is this? I can't find any mention in
> > Documention/CodingStyle. checkpatch.pl doesn't complain about them.
> > And there are almost three thousand examples in staging which don't
> > use this convention.
On Sat, Dec 13, 2014 at 07:07:05PM +, One Thousand Gnomes wrote:
>
> Pointless churn. It makes it less readable if anything, and it removes
> the type safety as you are now checking against 0 not (void *)0
>
> NAK
>
> Alan
The type safety is an interesting point I was not aware of.
Just in
Hi,
> The major reason is, it needs to read full 512KB segment to calculate
> checksum to
> know if the log isn't half written.
> (Read 500GB SSD that performs 500MB/sec seqread spends 1000secs)
I've just measured how long the cache resuming is.
I use 2GB SSD for the cache device.
512KB seqread
On Sat, Dec 13, 2014 at 6:07 AM, Akira Hayakawa wrote:
> Hi,
>
> Jianjian, You really get a point at the fundamental design.
>
>> If I understand it correctly, the whole idea indeed is very simple,
>> the consumer/provider and circular buffer model. use SSD as a circular
>> write buffer, write flu
Hi,
I've just measured how split affects.
I think seqread can make the discussion solid
so these are the cases of reading 6.4GB (64MB * 100) sequentially.
HDD:
64MB read
real 2m1.191s
user 0m0.000s
sys 0m0.470s
Writeboost (HDD+SSD):
64MB read
real 2m13.532s
user 0m0.000s
sy
Jianjian,
> How about invalidating previous writes on same sector address? if
> first write is stored in one 512KB log in SSD, later when user write
> the same address, will writeboost invalid old write by updating meta
> data header in place in that 512KB log? and other meta data like
> superblo
12 matches
Mail list logo
