linux-kernel - Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <45EC0DC7.8080504@t-online.de>
Date:	Mon, 05 Mar 2007 13:32:07 +0100
From:	Bernd Schmidt <bernds_cb1@...nline.de>
To:	Paul Mundt <lethal@...ux-sh.org>,
	"Wu, Bryan" <bryan.wu@...log.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update

Paul Mundt wrote:
>> +comment "Memory Optimizations"
>> +
>> +config I_ENTRY_L1
>> +	bool "Locate interrupt entry code in L1 Memory"
>> +	default y
>> +	help
>> +	  If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked
>> +	  into L1 instruction memory.(less latency)
>> +
> Wow, this is really crying out for a special linker section with slightly
> more intelligent relocation logic. You should flag the performance
> critical parts to be located in L1 memory directly with a section
> attribute, rather than making everything selectable. If you overflow you
> can simply spill in to main memory.

This is done intentionally, because it's also possible for user code to 
be loaded into L1 memory.  We want to give users the option to avoid 
filling it all up with kernel code.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough
-
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/