On 12/12/14 01:42, Akira Hayakawa wrote:
1. Writeboost shouldn't split the bio into 4KB chunks.
No. It is necessary.
I know WALB (https://github.com/starpos/walb) logs data without
splitting but the data structure becomes complicated.
If you read my code carefully, you will notice that splitting
On 12/12/14 6:12 PM, Bart Van Assche wrote:
This is the first time I see someone claiming that reducing the request size
improves performance. I don't know any SSD model for which splitting requests
improves performance.
Writeboost batches number of writes into a log (that is 512KB large)
On 12/12/14 00:53, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
On 12/12/14 10:35, Akira Hayakawa wrote:
Writeboost batches number of writes into a log (that is 512KB large) and
submits to SSD
which maximizes the throughput and the lifetime of the SSD.
Does this mean that dm-writeboost is similar to btier ? If so, this
makes me wonder which of these two
On Wed, Dec 10, 2014 at 10:54:35PM +0800, Matthew Tyler wrote:
This patch fixes a trailing statement warning found by checkpatch.pl
Signed-off-by: Matthew Tyler matt.ty...@flashics.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 7 ---
1 file changed, 4 insertions(+), 3
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
On Fri, 2014-12-12 at 12:35 +0100, Krzysztof Konopko wrote:
I'm _far_ from being a wireless expert but doesn't data coming out of
the wire/air have the endianess defined explicitly? And both `AC_param`
and `ADDBA_request` come out of air?
In general, data in 802.11 frames is little endian.
On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote:
The SSD-caching should be log-structured.
No argument there, and this is why I've supported you with
dm-writeboost over the last couple of years.
However, after looking at the current code, and using it I think it's
a long, long
However, after looking at the current code, and using it I think it's
a long, long way from being ready for production. As we've already
discussed there are some very naive design decisions in there, such as
copying every bio payload to another memory buffer, splitting all io
down to 4k.
On 12/12/2014 06:52 AM, Dan Carpenter wrote:
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
On Thu, 11 Dec 2014, One Thousand Gnomes wrote:
On Thu, 11 Dec 2014 09:43:24 +0800
kbuild test robot fengguang...@intel.com wrote:
drivers/staging/fpga/socfpga.c:655:25: sparse: symbol 'socfpga_fpga_ops'
was not declared. Should it be static?
Signed-off-by: Fengguang Wu
Krzysztof Konopko k...@konagma.com writes:
On 12/12/14 00:53, Larry Finger wrote:
In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned short.
That's not quite the case. `TXOP_limit` is __le16 in RTL8188EU [1].
It's __le16 even in your GitHub repo [2]. And that made me
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
On 12/12/14 00:53, Larry Finger wrote:
This fix may make the sparse warnings go away, but I think it introduces
new bugs.
Right, I see. Nice try though, isn't it? ;)
In particular, did you test on big-endian hardware after you
made this
On Tue, 9 Dec 2014 01:24:09 +0800
, Tsung-Han Lin tsunghan...@gmail.com
wrote:
Add dummy implementation of 'of_find_all_nodes',
and remove the unnecessary 'of_can_translate_address',
which is already removed in commit
d9c6866be8a145e32da616d8dcbae806032d75b5 (of: kill off
On 12/12/14 17:43, Larry Finger wrote:
On 12/12/2014 06:52 AM, Dan Carpenter wrote:
On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was
On 12/12/14 18:12, Jes Sorensen wrote:
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29:
On 12/12/14 18:35, Larry Finger wrote:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
On 12/12/14 00:53, Larry Finger wrote:
In particular, did you test on big-endian hardware after you
made this change?
Nope. I don't have any big-endian hardware. I don't even have the
wireless card
On 12/12/14 19:52, Jes Sorensen wrote:
Larry Finger larry.fin...@lwfinger.net writes:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
I was hunting particularly for inconsistencies with `sparse` and came
across this one. But I dug a bit further and I wonder why the driver is
not using
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted
On 12/12/2014 04:50 PM, Krzysztof Konopko wrote:
On 12/12/14 18:35, Larry Finger wrote:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
On 12/12/14 00:53, Larry Finger wrote:
In particular, did you test on big-endian hardware after you
made this change?
Nope. I don't have any big-endian
On Fri, 2014-12-12 at 23:58 +0100, Krzysztof Konopko wrote:
This patch changes the types of the struct fields involved to be
little-endian which is what is received over the air and consistent with
relevant structs in include/linux/ieee80211.h.
[]
diff --git
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 provider, and writeback thread write those data logs
sequentially into
23 matches
Mail list logo
