This patch removes the return statement at the end of a void function as
it is not necessary.This was found by checkpatch.pl .
Signed-off-by: Bhumika Goyal
---
drivers/staging/lustre/lustre/obdclass/llog_swab.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ob
Great! Thanks.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
This patch is to vb_table.h file that fixes up following warnings
reported by checkpatch.pl:
I) Block comments use * on subsequent lines.
Signed-off-by: YU Bo
---
drivers/staging/xgifb/vb_table.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/xgifb/vb_t
Hi Chen,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.4 next-20160114]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chen-Feng/staging-ion-make-the-pte
Hi Chen,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.4 next-20160114]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chen-Feng/staging-ion-make-the-pte
Since ion alloc can be called by userspace,eg gralloc.
When it is called frequently, the efficiency of kswapd is
to low. And the reclaimed memory is too lower. In this way,
the kswapd can use to much cpu resources.
With 3.5GB DMA Zone and 0.5 Normal Zone.
pgsteal_kswapd_dma 9364140
pgsteal_kswapd
The page is already alloc at ion_alloc function,
ion_mmap map the alloced pages to user-space.
The default prot can be PTE_RDONLY. Take a look at
here:
set_pte_at()
arch/arm64/include/asm:
if (pte_dirty(pte) && pte_write(pte))
pte_val(pte) &= ~PTE_RDONLY;
On Mon, Jan 11, 2016 at 12:52 PM, Hans Verkuil wrote:
> Did you also test with v4l2-compliance? Before I accept the driver I want to
> see the
> output of 'v4l2-compliance' and 'v4l2-compliance -s'. Basically there
> shouldn't be
> any failures.
>
> I did a quick scan over the source and I saw n
This patch is to vgatypes.h file that fixes up following warnings
reported by checkpatch.pl tool
Signed-off-by: YU Bo
---
drivers/staging/xgifb/vgatypes.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/xgifb/vgatypes.h b/drivers/staging/xgifb/
Commit f79b0d9c223c ("staging: speakup: Fixed warning
instead of ") broke the port information in the speakup
driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
and no other header includes asm/serial.h.
We here make sure serialio.c does get the arch-specific definition of
SE
> -Original Message-
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Thursday, January 14, 2016 5:08 PM
> To: Haiyang Zhang
> Cc: Tom Herbert ; One Thousand Gnomes
> ; David Miller ;
> vkuzn...@redhat.com; net...@vger.kernel.org; KY Srinivasan
> ; de...@linuxdriverproject.or
On Thu, 2016-01-14 at 20:23 +, Haiyang Zhang wrote:
>
> For non-random inputs, I used the port selection of iperf that increases
> the port number by 2 for each connection. Only send-port numbers are
> different, other values are the same. I also tested some other fixed
> increment, Toepl
From: Tom Herbert
Date: Thu, 14 Jan 2016 13:44:24 -0800
> The fact that we can negatively affect the output of Toeplitz so
> predictably is actually a liability and not a benefit. This sort of
> thing can be the basis of a DOS attack and is why we kicked out XOR
> hash in favor of Jenkins.
+1
T
On Thu, Jan 14, 2016 at 12:23 PM, Haiyang Zhang wrote:
>
>
>> -Original Message-
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Thursday, January 14, 2016 2:41 PM
>> To: Haiyang Zhang
>> Cc: Eric Dumazet ; One Thousand Gnomes
>> ; David Miller ;
>> vkuzn...@redhat.com; net...
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Thursday, January 14, 2016 2:41 PM
> To: Haiyang Zhang
> Cc: Eric Dumazet ; One Thousand Gnomes
> ; David Miller ;
> vkuzn...@redhat.com; net...@vger.kernel.org; KY Srinivasan
> ; de...@linuxdriverproject.org;
On Thu, Jan 14, 2016 at 11:15 AM, Haiyang Zhang wrote:
>
>
>> -Original Message-
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Thursday, January 14, 2016 1:49 PM
>> To: Haiyang Zhang
>> Cc: Eric Dumazet ; One Thousand Gnomes
>> ; David Miller ;
>> vkuzn...@redhat.com; net...
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Thursday, January 14, 2016 1:49 PM
> To: Haiyang Zhang
> Cc: Eric Dumazet ; One Thousand Gnomes
> ; David Miller ;
> vkuzn...@redhat.com; net...@vger.kernel.org; KY Srinivasan
> ; de...@linuxdriverproject.org;
On Thu, Jan 14, 2016 at 10:35 AM, Haiyang Zhang wrote:
>
>
>> -Original Message-
>> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
>> Sent: Thursday, January 14, 2016 1:24 PM
>> To: One Thousand Gnomes
>> Cc: Tom Herbert ; Haiyang Zhang
>> ; David Miller ;
>> vkuzn...@redhat.com; net.
> -Original Message-
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Thursday, January 14, 2016 1:24 PM
> To: One Thousand Gnomes
> Cc: Tom Herbert ; Haiyang Zhang
> ; David Miller ;
> vkuzn...@redhat.com; net...@vger.kernel.org; KY Srinivasan
> ; de...@linuxdriverproject.or
On Thu, 2016-01-14 at 17:53 +, One Thousand Gnomes wrote:
> > These results for Toeplitz are not plausible. Given random input you
> > cannot expect any hash function to produce such uniform results. I
> > suspect either your input data is biased or how your applying the hash
> > is.
> >
> > W
On Wed, 2016-01-13 at 23:10 +, Haiyang Zhang wrote:
> I have done a comparison of the Toeplitz v.s. Jenkins Hash algorithms,
> and found that the Toeplitz provides much better distribution of the
> connections into send-indirection-table entries. See the data below --
> showing how many TCP
> These results for Toeplitz are not plausible. Given random input you
> cannot expect any hash function to produce such uniform results. I
> suspect either your input data is biased or how your applying the hash
> is.
>
> When I run 64 random IPv4 3-tuples through Toeplitz and Jenkins I get
> som
> I have done a comparison of the Toeplitz v.s. Jenkins Hash algorithms,
> and found that the Toeplitz provides much better distribution of the
> connections into send-indirection-table entries. See the data below --
> showing how many TCP connections are distributed into each of the
> sixteen tabl
23 matches
Mail list logo
