Userspace API is 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
CC: David S. Miller
CC: linux-ker...@vger.kernel.org
CC: netdev@vger.
On 02/12/2018 06:47 PM, David Miller wrote:
From: Denys Vlasenko
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 on success.
"int *sockle
Userspace API is 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
CC: David S. Miller
CC: linux-ker...@vger.kernel.org
CC: netdev@vger.
+ /* 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 happeni
igned-off-by: Denys Vlasenko
CC: Vlad Yasevich
CC: Neil Horman
CC: David Miller
CC: linux-s...@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
Changed since v1:
* reindented function argument list
net/sctp/ulpevent.c | 2 +-
1 file changed, 1 insertion(+), 1 del
igned-off-by: Denys Vlasenko
CC: Vlad Yasevich
CC: Neil Horman
CC: David Miller
CC: linux-s...@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
net/sctp/ulpevent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/ulpevent.c b/net
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
CC: Felix Manlunas
CC: Prasad Kanneganti
C
Hello,
I would like to discuss this commit:
commit d3d7e6c65f75de18ced10a98595a847f9f95f0ce
Author: Raghu Vatsavayi
Date: Tue Jun 21 22:53:07 2016 -0700
liquidio: Firmware image download
This patch has firmware image related changes for: firmware
release upon failure, support lat
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
CC: Jeff Kirsher
CC: "Ruinskiy
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
f.
"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
CC: Jeff Kirsher
CC:
"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 fix it.
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
CC: Jeff Kirsher
CC: Jesse
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
CC: David S. Miller
CC: linux-ker...@vger.kernel.org
CC: netdev@vger.kernel.org
---
drivers/net/ethernet/jme.
atch fixes 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
C
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
CC: Vlad Yasevich
CC: Neil Horman
CC: Marcelo Ricard
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
CC: Thomas
On 07/16/2015 08:17 PM, David Miller wrote:
> From: Tom Herbert
> Date: Thu, 16 Jul 2015 08:43:25 -0700
>
>> On Thu, Jul 16, 2015 at 5:40 AM, Denys Vlasenko wrote:
>>> This patch deinlines jhash, jhash2 and __jhash_nwords.
>>>
>>> It also removes rhasht
vmlinux.after
Signed-off-by: Denys Vlasenko
CC: Thomas Graf
CC: Alexander Duyck
CC: Jozsef Kadlecsik
CC: Herbert Xu
CC: netdev@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
Changes in v2: created a new source file, jhash.c
include/linux/jhash.h | 123
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
CC
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
CC: John Linville
CC: Michal Kazior
Cc: Johannes Berg
Cc: linux-wirel...@vger.kernel.org
On Tue, Jul 14, 2015 at 2:38 PM, Sergei Shtylyov
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); \
>> + iwl_trans_write8(trans, 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
CC: Johannes Berg
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
CC: David S. Miller
CC: linux-ker...@vger.kernel.org
CC: netdev@vger.kernel.org
---
drivers/net/ethernet/3com/3c59x.c | 6 +-
1
On Wed, Apr 1, 2015 at 9:48 PM, David Miller 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 apparently it doesn't
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
> ter
data bss dec hex filename
82447071 22255384 20627456 125329911 77861f7 vmlinux4
82441375 22255384 20627456 125324215 7784bb7 vmlinux5prime
Signed-off-by: Denys Vlasenko
CC: Eric W. Biederman
CC: David S. Miller
CC: Jan Engelhardt
CC: Jiri Pirko
CC: linux-ker...@vger.kernel.
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 co
p if you tell me how I should change the patches.
(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
> Date: Tue, 14 Apr 2015 14:25:11 +0200
>
>> On
On Monday 31 December 2007 17:00, Patrick McHardy wrote:
> Denys Vlasenko wrote:
> > ip[6]_tables.c seem to abuse inline.
> >
> > This patch removes inlines except those which are used
> > by packet matching code and thus are performance-critical.
> >
>
>
es.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Please take this patch into netfilter queue.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff --git a/net/ipv4/netfilter/ip_tables.c
On Monday 17 December 2007 14:47, Patrick McHardy wrote:
> Please CC netfilter-devel on netfilter patches.
>
> Denys Vlasenko wrote:
> > Hi Patrick, Harald,
> >
> > I was working on unrelated problem and noticed that ip_tables.c
> > seem to abuse inline. I prepa
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 PROTEC
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 li
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'
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
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
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
ound
> zlib_inflate_blob() and those troublesome includes. A nicer fix is
> probably to change the zlib_inflate_blob() interface to pass in
> pointers to alloc() and free() routines instead of calling kernel ones
> directly.
>
> Denys?
>
> commit 8336793baf962163c9fab5a
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
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
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
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 l
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.
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 &
, 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/
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 t
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 */
> +
6424 143523 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-&
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.
Yo
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;
> >
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:
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 unfort
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:
>
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 think
> > people want "volatile" keyword per se, th
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 generat
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. h
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 situation
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();
>
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 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 yo
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'
64 matches
Mail list logo
