On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
For less-than-briliant people like me, it's
On Saturday 18 August 2007 05:13, Linus Torvalds wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
No code does (or would do, or should do):
x.counter++;
on an atomic_t x; anyway.
That's just an example of a general problem.
No, you don't use x.counter++. But you *do* use
On Thursday 16 August 2007 00:22, Paul Mackerras wrote:
Satyam Sharma writes:
In the kernel we use atomic variables in precisely those situations
where a variable is potentially accessed concurrently by multiple
CPUs, and where each CPU needs to see updates done by other CPUs in a
timely
On Friday 24 August 2007 13:12, Kenn Humborg wrote:
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
On Friday 24 August 2007 18:15, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
On Thursday 16 August 2007 00:22, Paul Mackerras wrote:
Satyam Sharma writes:
In the kernel we use atomic variables in precisely those situations
where a variable is potentially accessed
On Friday 24 August 2007 18:06, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Satyam Sharma wrote:
But if people do seem to have a mixed / confused notion of atomicity
and barriers, and if there's consensus, then as I'd said earlier, I
have no issues in going with the consensus (eg. having
On Friday 17 August 2007 17:48, Linus Torvalds wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
That's not obviously just taste to me. Not when the primitive has many
(perhaps, the majority) of uses that do not require said barriers. And
this is not solely about the code generation
On Monday 10 September 2007 13:22, Kyle Moffett wrote:
On Sep 10, 2007, at 06:56:29, Denys Vlasenko wrote:
On Sunday 09 September 2007 19:18, Arjan van de Ven wrote:
On Sun, 9 Sep 2007 19:02:54 +0100
Denys Vlasenko [EMAIL PROTECTED] wrote:
Why is all this fixation on volatile? I don't
On Monday 10 September 2007 14:38, Denys Vlasenko wrote:
You are basically trying to educate me how to use atomic properly.
You don't need to do it, as I am (currently) not a driver author.
I am saying that people who are already using atomic_read()
(and who unfortunately did not read your
On Monday 10 September 2007 15:51, Arjan van de Ven wrote:
On Mon, 10 Sep 2007 11:56:29 +0100
Denys Vlasenko [EMAIL PROTECTED] wrote:
Well, if you insist on having it again:
Waiting for atomic value to be zero:
while (atomic_read(x))
continue
On Monday 10 September 2007 16:09, Linus Torvalds wrote:
On Mon, 10 Sep 2007, Denys Vlasenko wrote:
static inline int
qla2x00_wait_for_loop_ready(scsi_qla_host_t *ha)
{
int return_status = QLA_SUCCESS;
unsigned long loop_timeout ;
scsi_qla_host_t *pha
On Tuesday 18 September 2007 19:45, Michael Chan wrote:
We can compress all the different sections of the firmware. Currently,
we only compress the biggest chunks and the rest are uncompressed.
These zeros should compress to almost nothing. But I agree that the
firmware is still big.
You
230a3 net.org/bnx2.o
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED]
--
vda
--- linux-2.6.23-rc6.org/drivers/net/bnx2.c Tue Sep 11 22:33:54 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2.c Wed Sep 19 00:01:19 2007
@@ -2767,93 +2767,61 @@
spin_unlock_bh(bp-phy_lock);
}
-#define FW_BUF_SIZE
On Wednesday 19 September 2007 22:00, Michael Chan wrote:
On Wed, 2007-09-19 at 09:30 +0100, Denys Vlasenko wrote:
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+* is stripped, 32-bit unpacked size (LE) is prepended instead */
+ sz = *zbuf
On Wednesday 19 September 2007 22:43, Michael Chan wrote:
On Wed, 2007-09-19 at 21:29 +0100, Denys Vlasenko wrote:
Are you saying that you successfully run-tested it?
I've only reviewed the code. Let's resolve these issues first before
testing the code.
Please test these two patches.
I
On Friday 21 September 2007 12:01, Denys Vlasenko wrote:
I will move this code
out of the driver and into zlib in follow-on patch.
No, I won't. I accidentally attached both patches to first email,
you can find it there. Sorry.
--
vda
-
To unsubscribe from this list: send the line unsubscribe
, cursor bitmaps,
whatever.
Patch is run tested by Michael Chan (driver author).
Michael, can you add your ACK?
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN linux-2.6.23-rc6/drivers/net/bnx2.c linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c
--- linux-2.6.23-rc6/drivers/net/bnx2.c
On Friday 21 September 2007 17:14, David Miller wrote:
From: Denys Vlasenko [EMAIL PROTECTED]
Date: Fri, 21 Sep 2007 12:01:24 +0100
Hi Jeff,
BNX2 and TG3 patches goes through Michael Chan and myself,
and I usually merge them in instead of Jeff.
Didn't know that, sorry.
Do patches look
On Friday 21 September 2007 18:49, David Miller wrote:
From: Denys Vlasenko [EMAIL PROTECTED]
Date: Fri, 21 Sep 2007 18:03:55 +0100
Do patches look ok to you?
I'm travelling so I haven't looked closely yet :-)
Michael can take a look and I'll try to do so as well
tonight.
Good.
I
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
I plan to use gzip compression on following drivers' firmware,
if patches will be accepted:
textdata bss dec hex filename
17653 109968 240
On Friday 21 September 2007 21:13, Andi Kleen wrote:
Denys Vlasenko [EMAIL PROTECTED] writes:
I plan to use gzip compression on following drivers' firmware,
if patches will be accepted:
textdata bss dec hex filename
17653 109968 240 127861 1f375 drivers
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
On Fri, 21 Sep 2007, Denys Vlasenko wrote:
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
I plan to use gzip compression on following drivers' firmware
() routines instead of calling kernel ones
directly.
Denys?
commit 8336793baf962163c9fab5a3f39614295fdbab27
Author: Denys Vlasenko [EMAIL PROTECTED]
Date: Sun Sep 30 17:56:49 2007 -0700
[ZLIB]: Move bnx2 driver gzip unpacker into zlib.
Signed-off-by: Denys Vlasenko [EMAIL
On Friday 12 October 2007 05:09, Paul Mackerras wrote:
I supposed a hacky fix is to add __KERNEL__ ifdef protection around
zlib_inflate_blob() and those troublesome includes. A nicer fix is
That would do, but I don't see why zlib_inflate_blob had to be added
to inflate.c rather than being
On Tuesday 13 November 2007 07:08, Mark Lord wrote:
Ingo Molnar wrote:
..
This is all QA-101 that _cannot be argued against on a rational basis_,
it's just that these sorts of things have been largely ignored for
years, in favor of the all-too-easy open source means many eyeballs and
On Tuesday 13 November 2007 10:56, Adrian Bunk wrote:
On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote:
On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote:
Btw, I used to test every -mm kernel. But since I've switched distros
(gentoo-ubuntu)
and I have less
On Tuesday 13 November 2007 11:57, Gabriel C wrote:
The main problem is finding experienced developers who spend time on
looking into bug reports.
There are already. IMO the problem is the development model.
There are tons new features in each new kernel release and 'tons new bugs'
which
On Wednesday 14 November 2007 00:27, Adrian Bunk wrote:
You missed the following in my email:
we slowly scare them away due to the many bug reports without any
reaction.
The problem is that bug reports take time. If you go away from easy
things like compile errors then even things like
are
performance critical.
Result as reported by size:
textdata bss dec hex filename
- 6451 380 8869191b07 ip_tables.o
+ 6339 348 7267591a67 ip_tables.o
Please take this patch into netfilter queue.
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED
On Wed, Apr 1, 2015 at 9:48 PM, David Miller da...@davemloft.net wrote:
D.S. Ljungmark (1):
ipv6: Don't reduce hop limit for an interface
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6fd99094de2b83d1d4c8457f2c83483b2828e75a
I was testing this change and
.
(I also hope to have a semi-generic way of addressing
performance concerns for future deinlining
patch submissions.)
On 04/14/2015 08:37 PM, David Miller wrote:
From: Denys Vlasenko dvlas...@redhat.com
Date: Tue, 14 Apr 2015 14:25:11 +0200
On x86 allyesconfig build:
The function compiles
On 04/17/2015 07:42 PM, Eric Dumazet wrote:
On Fri, 2015-04-17 at 19:05 +0200, Denys Vlasenko wrote:
How do you expect one to find excessively large inlines,
if not on allyesconfig build?
Tuning kernel sources based on allyesconfig build _size_ only is
terrible. We could build
dec hex filename
82447071 22255384 20627456 125329911 77861f7 vmlinux4
82441375 22255384 20627456 125324215 7784bb7 vmlinux5prime
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Eric W. Biederman ebied...@xmission.com
CC: David S. Miller da...@davemloft.net
CC: Jan Engelhardt jeng
On 04/16/2015 02:38 PM, Eric Dumazet wrote:
On Thu, 2015-04-16 at 13:14 +0200, Denys Vlasenko wrote:
However, without BUG_ONs, function is still a bit big
on PREEMPT configs.
Only on allyesconfig builds, that nobody use but to prove some points
about code size.
How do you expect one
to be called.
vortex_interrupt() has it right: it returns IRQ_NONE in this case
via IRQ_RETVAL(0).
Do the same in boomerang_interrupt().
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: David S. Miller da...@davemloft.net
CC: linux-ker...@vger.kernel.org
CC: netdev@vger.kernel.org
---
drivers
On Tue, Jul 14, 2015 at 2:38 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
+#define IWL_READ_WRITE(static_inline) \
+static_inline void iwl_write8(struct iwl_trans *trans, u32 ofs, u8 val) \
+{ \
+ trace_iwlwifi_dev_iowrite8(trans-dev, ofs, val); \
+
callsites
iwl_write8 493 bytes, 3 callsites
Reduction in size is about 74,000 bytes:
text data bss dec hex filename
90758147 17226024 36659200 144643371 89f152b vmlinux0
90687995 17221928 36659200 144569123 89df323 vmlinux.after
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
vmlinux.after
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Thomas Graf tg...@suug.ch
CC: Alexander Duyck alexander.h.du...@redhat.com
CC: Jozsef Kadlecsik kad...@blackhole.kfki.hu
CC: Herbert Xu herb...@gondor.apana.org.au
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
Changes
bytes, 111 calls
jhash2: 205 bytes, 136 calls
Total size decrease is about 33,000 bytes:
text data bss dec hex filename
90663567 17221960 36659200 144544727 89d93d7 vmlinux5
90630370 17221864 36659200 144511434 89d11ca vmlinux.after
Signed-off-by: Denys Vlasenko dvlas
On 07/16/2015 08:17 PM, David Miller wrote:
From: Tom Herbert t...@herbertland.com
Date: Thu, 16 Jul 2015 08:43:25 -0700
On Thu, Jul 16, 2015 at 5:40 AM, Denys Vlasenko dvlas...@redhat.com wrote:
This patch deinlines jhash, jhash2 and __jhash_nwords.
It also removes rhashtable_jhash2(key
With this .config: http://busybox.net/~vda/kernel_config,
after deinlining the function size is 3132 bytes and there are
7 callsites.
Total size reduction: about 20 kbytes.
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: John Linville linvi...@tuxdriver.com
CC: Michal Kazior michal.kaz
With this .config: http://busybox.net/~vda/kernel_config,
after deinlining these functions have sizes and callsite counts
as follows:
rate_control_rate_init: 554 bytes, 8 calls
rate_control_rate_update: 1596 bytes, 5 calls
Total size reduction: about 11 kbytes.
Signed-off-by: Denys Vlasenko
On 09/28/2015 05:32 PM, David Laight wrote:
> From: Eric Dumazet
>> Sent: 28 September 2015 15:27
>> On Mon, 2015-09-28 at 14:12 +, David Laight wrote:
>>> From: Neil Horman
>>>> Sent: 28 September 2015 14:51
>>>> On Mon, Sep 28, 2015 at 02:34:0
Seemingly innocuous sctp_trans_state_to_prio_map[] array
is way bigger than it looks, since
"[SCTP_UNKNOWN] = 2" expands into "[0x] = 2" !
This patch replaces it with switch() statement.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: Vlad Yasevich <
this via s/inline/__always_inline/.
Code size decrease after the patch is ~2.5k:
text data bss dec hex filename
56719876 56364551 36196352 149280779 8e5d80b vmlinux_before
56717440 56364551 36196352 149278343 8e5ce87 vmlinux
Signed-off-by: Denys Vlasenko <dv
This function compiles to 895 bytes of machine code.
Clearly, this isn't a time-critical function.
For one, it has a number of udelay(1) calls.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: David S. Miller <da...@davemloft.net>
CC: linux-ker...@vger.kernel.or
rem = do_div(temp, incvalue);
This change makes kernel survive this, and users report that
NIC does work after this change.
Since on real hardware incvalue is never zero, this should not affect
real hardware use case.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: Jeff Kirsher <
On 04/19/2016 10:57 PM, Jeff Kirsher wrote:
> On Tue, 2016-04-19 at 14:34 +0200, Denys Vlasenko wrote:
>> "incvalue" variable holds a result of "er32(TIMINCA) &
>> E1000_TIMINCA_INCVALUE_MASK"
>> and used in "do_div(temp, incvalue)" as a divi
"incvalue" variable holds a result of "er32(TIMINCA) &
E1000_TIMINCA_INCVALUE_MASK"
and used in "do_div(temp, incvalue)" as a divisor.
Thus, "u64 incvalue" declaration is probably a mistake.
Even though it seems to be a harmless one, let's f
increments.
We do two reads, er32(SYSTIML) and er32(SYSTIMH), in this order.
Even if one increment happens between them, the overflow into SYSTIMH
is impossible, and we can avoid doing another er32(SYSTIML) read
and overflow check.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC
.
"systimel_1 < systimel_2" is false, we think it's an overflow,
we read "systimeh = er32(SYSTIMH)" which meanwhile had incremented,
and use "(systimeh << 32) + systimel_2" value which is 2^32 too large.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com&
+ /* Reading from resource space should be 32b aligned */
+ fw_maj_min = ioread32be(fw_ver);
+ fw_sub_min = ioread32be(fw_ver + 1);
+ fw_major = fw_maj_min & 0x;
+ fw_minor = fw_maj_min >> 16;
+ fw_subminor = fw_sub_min & 0x;
Maybe second read should be
On 06/21/2017 09:24 PM, Marcelo Ricardo Leitner wrote:
On Wed, Jun 21, 2017 at 07:03:27PM +0200, Denys Vlasenko wrote:
This function compiles to 147 bytes of machine code. 13 callsites.
I'm no expert on SCTP events, but quick reading of SCTP docs tells me that
SCTP events are not happening
Only compile-tested - I don't have the hardware.
>From code inspection, octeon_pci_write_core_mem() appears to be safe wrt
unaligned source. In any case, u8 fbuf[] was not guaranteed to be aligned
anyway.
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: Felix Manlunas <
-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: Vlad Yasevich <vyasev...@gmail.com>
CC: Neil Horman <nhor...@tuxdriver.com>
CC: David Miller <da...@davemloft.net>
CC: linux-s...@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
net/sctp/u
-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: Vlad Yasevich <vyasev...@gmail.com>
CC: Neil Horman <nhor...@tuxdriver.com>
CC: David Miller <da...@davemloft.net>
CC: linux-s...@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
Changed since v
not changed.
textdata bss dec hex filename
30108430 2633624 873672 33615726 200ef6e vmlinux.before.o
30108109 2633612 873672 33615393 200ee21 vmlinux.o
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: David S. Miller <da...@davemloft.net>
CC: linu
not changed.
textdata bss dec hex filename
30108430 2633624 873672 33615726 200ef6e vmlinux.before.o
30108109 2633612 873672 33615393 200ee21 vmlinux.o
Signed-off-by: Denys Vlasenko <dvlas...@redhat.com>
CC: David S. Miller <da...@davemloft.net>
CC: linu
On 02/12/2018 06:47 PM, David Miller wrote:
From: Denys Vlasenko <dvlas...@redhat.com>
Date: Mon, 12 Feb 2018 15:15:18 +0100
Before:
All these functions either return a negative error indicator,
or store length of sockaddr into "int *socklen" parameter
and return zero o
59 matches
Mail list logo
