lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sun, 9 Sep 2007 11:48:11 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	linux-scsi@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 16/22] advansys: Eliminate prototypes

On Sun, Sep 09, 2007 at 11:29:34AM -0400, Jeff Garzik wrote:
> What thoughts, if any, have been given to post-patch code arrangement, 
> besides eliminating prototypes?
> This always struck me as a counterproductive exercise when taken by 
> itself.

Eliminating prototypes saves me from an extra go round of the edit-compile
testcycle when I change the signature of a function.  It probably doesn't
matter to you, but it adds a small amount of annoyance to my day.

> Sure, prototypes were eliminated, but was code packed together 
> in an efficient way afterwards?  Ideally hot path code should be close 
> together, ditto for various other things like error handling code.

I tried to place functions close together that seemed like they were
called together and called from each other.   It's hard to know,
of course, because GCC will make its own decisions about inlining,
for example.  At the end of the day, this is an NP problem.  I remmber
Nat writing grope and using simulated annealing to solve the problem.

> Without further explanation or details about your post-patch analysis, 
> how do we even know the new code arrangement doesn't negatively impact 
> i-cache overall?

We don't, but the new layout is more likely to be good than bad, given
how I did the rearrangement (delete prototypes, try to compile.  Move
called function to before its first caller.  Repeat).  Plus, with all
the other changes I'm making, there's a serious reduction in driver
size.  I haven't compared i-cache sizes specifically, but I'm mostly
removing code, so it should be better.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists