Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH 3/3] x86, extable: Handle early exceptions

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


bp at amd64

Apr 19, 2012, 2:26 AM

Post #1 of 22 (219 views)
Permalink
[PATCH 3/3] x86, extable: Handle early exceptions

From: Borislav Petkov <bp [at] alien8>
Date: Sun, 1 Apr 2012 11:33:29 +0200
Subject: [PATCH 3/3] x86, extable: Handle early exceptions

Now that all is in place, wire in exception handling into the early IDT
handler.

Also, move the sorting of the main exception table earlier in the boot
process now that we handle exceptions in the early IDT handler too.

Signed-off-by: Borislav Petkov <bp [at] alien8>
---
arch/x86/kernel/head64.c | 6 ++++++
arch/x86/kernel/head_64.S | 5 +++++
arch/x86/mm/extable.c | 12 ++++++++++++
init/main.c | 1 -
4 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 3a3b779f41d3..20860aa44747 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -13,6 +13,7 @@
#include <linux/start_kernel.h>
#include <linux/io.h>
#include <linux/memblock.h>
+#include <linux/module.h> /* sort_main_extable() */

#include <asm/processor.h>
#include <asm/proto.h>
@@ -79,6 +80,11 @@ void __init x86_64_start_kernel(char * real_mode_data)

max_pfn_mapped = KERNEL_IMAGE_SIZE >> PAGE_SHIFT;

+ /* We're going to enable the initial exception handlers and we need the
+ * exception table sorted prior to that.
+ */
+ sort_main_extable();
+
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
set_intr_gate(i, &early_idt_handlers[i]);
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 40f4eb3766d1..7e6661d97e9d 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -282,6 +282,11 @@ early_idt_handlers:
#endif

ENTRY(early_idt_handler)
+ call early_fixup_exception
+ cmpq $0, %rax
+ jz 2f
+ retq
+2:
#ifdef CONFIG_EARLY_PRINTK
cmpl $2,early_recursion_flag(%rip)
jz 1f
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 08aecb0d3132..f8ed1ce07f4c 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -19,6 +19,18 @@ static void pnp_bios_is_crap(unsigned long cs)
#endif
}

+asmlinkage int early_fixup_exception(struct pt_regs *regs)
+{
+ const struct exception_table_entry *fixup;
+
+ fixup = search_main_extable(regs->ip);
+ if (!fixup)
+ return 0;
+
+ regs->ip = fixup->fixup;
+ return 1;
+}
+
int fixup_exception(struct pt_regs *regs)
{
const struct exception_table_entry *fixup;
diff --git a/init/main.c b/init/main.c
index ff49a6dacfbb..8ef10a2e2892 100644
--- a/init/main.c
+++ b/init/main.c
@@ -517,7 +517,6 @@ asmlinkage void __init start_kernel(void)
setup_log_buf(0);
pidhash_init();
vfs_caches_init_early();
- sort_main_extable();
trap_init();
mm_init();

--
1.7.5.3.401.gfb674

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 10:02 AM

Post #2 of 22 (207 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 02:26 AM, Borislav Petkov wrote:
>
> Also, move the sorting of the main exception table earlier in the boot
> process now that we handle exceptions in the early IDT handler too.
>

I would much rather use David Daney's patchset to sort the exception
table at compile time:

https://lkml.org/lkml/2011/11/18/427

... and I would be *even happier* with an O(1) hash (which pretty much
*have* to be constructed at compile time.)

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Apr 19, 2012, 10:27 AM

Post #3 of 22 (206 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 10:02 AM, H. Peter Anvin <hpa [at] zytor> wrote:
>
> ... and I would be *even happier* with an O(1) hash (which pretty much
> *have* to be constructed at compile time.)

Taking relocations into account might be interesting for hashing. I
guess you could hash the relative offsets, though.

But yeah, a hash might be the way to go, and once you generate the
tables at compile-time, why not go all the way? It doesn't need to be
some complex perfect hash, it should be fairly straightforward to just
size the hash right and use some simple linear probing model for
collissions or whatever.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Apr 19, 2012, 10:38 AM

Post #4 of 22 (203 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 10:27:09AM -0700, Linus Torvalds wrote:
> On Thu, Apr 19, 2012 at 10:02 AM, H. Peter Anvin <hpa [at] zytor> wrote:
> >
> > ... and I would be *even happier* with an O(1) hash (which pretty much
> > *have* to be constructed at compile time.)
>
> Taking relocations into account might be interesting for hashing. I
> guess you could hash the relative offsets, though.
>
> But yeah, a hash might be the way to go, and once you generate the
> tables at compile-time, why not go all the way? It doesn't need to be
> some complex perfect hash, it should be fairly straightforward to just
> size the hash right and use some simple linear probing model for
> collissions or whatever.

Yeah, simplicity is the key here. I don't think we're getting that many
early boot exceptions due to rdmsr or whatever to warrant adding a bunch
of code.

OTOH, if we can share early and normal exception handling lookup code, then a
perfect hash would make sense as those exceptions would pile up.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 10:54 AM

Post #5 of 22 (203 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 10:02 AM, H. Peter Anvin wrote:
> On 04/19/2012 02:26 AM, Borislav Petkov wrote:
>>
>> Also, move the sorting of the main exception table earlier in the boot
>> process now that we handle exceptions in the early IDT handler too.
>>
>
> I would much rather use David Daney's patchset to sort the exception
> table at compile time:
>
> https://lkml.org/lkml/2011/11/18/427
>
> ... and I would be *even happier* with an O(1) hash (which pretty much
> *have* to be constructed at compile time.)
>

The sorting is easier infrastructure-wise, since it can be done
in-place. The O(1) hash needs additional space for the hash table
itself (the actual table can still be stashed where the compiler
generates it.)

The hash table generator I have posted at:

http://www.zytor.com/~hpa/phash/

Generally needs ~3.2 bytes per hash table entry, rounded up to a power
of two. The rounding up is for performance. The easiest way to do this
is probably to let the linker create a zero-filled section of the proper
size (since the linker knows the final size of the __ex_table section,
and the linker script can do at least a modicum of arithmetic) and then
use a tool to patch in the hash table auxilliary data.

-hpa


P.S. Another modification which was talked about in the past and there
even were patches for was to make the exception table entries relative
to the start of the kernel, so we don't need two relocations per entry
for x86-32 and twice the amount of data that we can actually use for
x86-64. As I recall we tried those patches and there was some bug that
never got resolved.

This is obviously a precondition for doing the O(1) hash, since the O(1)
hash can't be relocated once generated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 10:59 AM

Post #6 of 22 (205 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 10:38 AM, Borislav Petkov wrote:
>
> Yeah, simplicity is the key here. I don't think we're getting that many
> early boot exceptions due to rdmsr or whatever to warrant adding a bunch
> of code.
>
> OTOH, if we can share early and normal exception handling lookup code, then a
> perfect hash would make sense as those exceptions would pile up.
>

Obviously we should use the hash after the main kernel is up, too.
Anything else would be silly.

I would argue that the O(1) hash makes things simpler as there is no
need to deal with collisions at all. The one advantage with "plain"
hashes is that can be runtime modified, which would be of some interest
if we create one single hash table that includes modules.

*That* seems complex to me, though.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Apr 19, 2012, 11:11 AM

Post #7 of 22 (204 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 10:38 AM, Borislav Petkov <bp [at] amd64> wrote:
>
> OTOH, if we can share early and normal exception handling lookup code, then a
> perfect hash would make sense as those exceptions would pile up.

Oh, any of this only makes sense if we can share it with the runtime
exception lookup.

They are *seldom* hugely performance-critical, but there are some
unusual loads where you do get a fair number of exceptions.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Apr 19, 2012, 11:25 AM

Post #8 of 22 (202 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 10:59 AM, H. Peter Anvin <hpa [at] zytor> wrote:
>
> I would argue that the O(1) hash makes things simpler as there is no
> need to deal with collisions at all.

Most of the O(1) hashes I have seen more than made up for the trivial
complexity of a few linear lookups by making the hash function way
more complicated.

A linear probe with a step of one really is pretty simple. Sure, you
might want to make the initial hash "good enough" to not often hit the
probing code, but doing a few linear probes is cheap.

In contrast, the perfect linear hashes do crazy things like having
table lookups *JUST TO COMPUTE THE HASH*.

Which is f*cking stupid, really. They'll miss in the cache just at
hash compute time, never mind at hash lookup. The table-driven
versions look beautiful in microbenchmarks that have the tables in the
L1 cache, but for something like the exception handling, I can
guarantee that *nothing* is in L1, and probably not even L2.

So what you want is:
- no table lookups for hashing
- simple code (ie a normal "a multiply and a shift/mask or two") to
keep the I$ footprint down too
- you *will* take a cache miss on the actual hash table lookup, that
cannot be avoided, but linear probing at least hopefully keeps it to
that single cache miss even if you have to do a probe or two.

Remember: this is very much a "cold-cache behavior matters" case. We
would never ever call this in a loop, at most we have loads that get a
fair amount of exceptions (but will go through the exception code, so
the L1 is probably blown even then).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 11:55 AM

Post #9 of 22 (205 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

Either way I suggest picking up David's presorting patchset since it is already done and use its infrastructure for any further improvements.

As far as a linear probe you get an average of n lookups with a packing density of 1-1/n so you are right; a linear probe with a density of say 1/2 is probably best.

Linus Torvalds <torvalds [at] linux-foundation> wrote:

>On Thu, Apr 19, 2012 at 10:59 AM, H. Peter Anvin <hpa [at] zytor> wrote:
>>
>> I would argue that the O(1) hash makes things simpler as there is no
>> need to deal with collisions at all.
>
>Most of the O(1) hashes I have seen more than made up for the trivial
>complexity of a few linear lookups by making the hash function way
>more complicated.
>
>A linear probe with a step of one really is pretty simple. Sure, you
>might want to make the initial hash "good enough" to not often hit the
>probing code, but doing a few linear probes is cheap.
>
>In contrast, the perfect linear hashes do crazy things like having
>table lookups *JUST TO COMPUTE THE HASH*.
>
>Which is f*cking stupid, really. They'll miss in the cache just at
>hash compute time, never mind at hash lookup. The table-driven
>versions look beautiful in microbenchmarks that have the tables in the
>L1 cache, but for something like the exception handling, I can
>guarantee that *nothing* is in L1, and probably not even L2.
>
>So what you want is:
> - no table lookups for hashing
> - simple code (ie a normal "a multiply and a shift/mask or two") to
>keep the I$ footprint down too
> - you *will* take a cache miss on the actual hash table lookup, that
>cannot be avoided, but linear probing at least hopefully keeps it to
>that single cache miss even if you have to do a probe or two.
>
>Remember: this is very much a "cold-cache behavior matters" case. We
>would never ever call this in a loop, at most we have loads that get a
>fair amount of exceptions (but will go through the exception code, so
>the L1 is probably blown even then).
>
> Linus

--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ddaney.cavm at gmail

Apr 19, 2012, 1:17 PM

Post #10 of 22 (196 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 11:55 AM, H. Peter Anvin wrote:
> Either way I suggest picking up David's presorting patchset since it is already done and use its infrastructure for any further improvements.
>

It does have the advantage of already being implemented. There was a
little feedback on the kbuild portions of the patch.

If you would like, I will send an updated version of the patch.

> As far as a linear probe you get an average of n lookups with a packing density of 1-1/n so you are right; a linear probe with a density of say 1/2 is probably best.
>

I usually see exception table sizes on the order of 2^10 entries, so I
have to wonder how much you really gain from an O(1) implementation.

David Daney

> Linus Torvalds<torvalds [at] linux-foundation> wrote:
>
>> On Thu, Apr 19, 2012 at 10:59 AM, H. Peter Anvin<hpa [at] zytor> wrote:
>>>
>>> I would argue that the O(1) hash makes things simpler as there is no
>>> need to deal with collisions at all.
>>
>> Most of the O(1) hashes I have seen more than made up for the trivial
>> complexity of a few linear lookups by making the hash function way
>> more complicated.
>>
>> A linear probe with a step of one really is pretty simple. Sure, you
>> might want to make the initial hash "good enough" to not often hit the
>> probing code, but doing a few linear probes is cheap.
>>
>> In contrast, the perfect linear hashes do crazy things like having
>> table lookups *JUST TO COMPUTE THE HASH*.
>>
>> Which is f*cking stupid, really. They'll miss in the cache just at
>> hash compute time, never mind at hash lookup. The table-driven
>> versions look beautiful in microbenchmarks that have the tables in the
>> L1 cache, but for something like the exception handling, I can
>> guarantee that *nothing* is in L1, and probably not even L2.
>>
>> So what you want is:
>> - no table lookups for hashing
>> - simple code (ie a normal "a multiply and a shift/mask or two") to
>> keep the I$ footprint down too
>> - you *will* take a cache miss on the actual hash table lookup, that
>> cannot be avoided, but linear probing at least hopefully keeps it to
>> that single cache miss even if you have to do a probe or two.
>>
>> Remember: this is very much a "cold-cache behavior matters" case. We
>> would never ever call this in a loop, at most we have loads that get a
>> fair amount of exceptions (but will go through the exception code, so
>> the L1 is probably blown even then).
>>
>> Linus
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 1:20 PM

Post #11 of 22 (195 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 01:17 PM, David Daney wrote:
> On 04/19/2012 11:55 AM, H. Peter Anvin wrote:
>> Either way I suggest picking up David's presorting patchset since it
>> is already done and use its infrastructure for any further improvements.
>
> It does have the advantage of already being implemented. There was a
> little feedback on the kbuild portions of the patch.
>
> If you would like, I will send an updated version of the patch.

Please. It gets us 90% of the way, and we need the infrastructure
anyway to do any further work.

>> As far as a linear probe you get an average of n lookups with a
>> packing density of 1-1/n so you are right; a linear probe with a
>> density of say 1/2 is probably best.
>>
>
> I usually see exception table sizes on the order of 2^10 entries, so I
> have to wonder how much you really gain from an O(1) implementation.

Well, for either variant of hash table you end up with ~2 serial memory
references as opposed to ~11. No idea if there are workloads where this
actually matters.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 1:26 PM

Post #12 of 22 (198 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 01:20 PM, H. Peter Anvin wrote:
> On 04/19/2012 01:17 PM, David Daney wrote:
>> On 04/19/2012 11:55 AM, H. Peter Anvin wrote:
>>> Either way I suggest picking up David's presorting patchset since it
>>> is already done and use its infrastructure for any further improvements.
>>
>> It does have the advantage of already being implemented. There was a
>> little feedback on the kbuild portions of the patch.
>>
>> If you would like, I will send an updated version of the patch.
>
> Please. It gets us 90% of the way, and we need the infrastructure
> anyway to do any further work.
>

Linus, it's not really an x86 patchset, but would you object if I queue
up David's updated patchset in -tip? I'll try to get an Ack from Ralf
for the MIPS portion.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


david.daney at cavium

Apr 19, 2012, 1:40 PM

Post #13 of 22 (193 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 01:26 PM, H. Peter Anvin wrote:
> On 04/19/2012 01:20 PM, H. Peter Anvin wrote:
>> On 04/19/2012 01:17 PM, David Daney wrote:
>>> On 04/19/2012 11:55 AM, H. Peter Anvin wrote:
>>>> Either way I suggest picking up David's presorting patchset since it
>>>> is already done and use its infrastructure for any further improvements.
>>>
>>> It does have the advantage of already being implemented. There was a
>>> little feedback on the kbuild portions of the patch.
>>>
>>> If you would like, I will send an updated version of the patch.
>>
>> Please. It gets us 90% of the way, and we need the infrastructure
>> anyway to do any further work.
>>
>
> Linus, it's not really an x86 patchset, but would you object if I queue
> up David's updated patchset in -tip? I'll try to get an Ack from Ralf
> for the MIPS portion.
>

I am looking at the patch right now to see if I want to revise it in any
way. Very Soon Now I will either send a new version, or indicate that I
think the existing version is good enough.

David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Apr 19, 2012, 2:47 PM

Post #14 of 22 (196 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 1:26 PM, H. Peter Anvin <hpa [at] zytor> wrote:
>
> Linus, it's not really an x86 patchset, but would you object if I queue
> up David's updated patchset in -tip? áI'll try to get an Ack from Ralf
> for the MIPS portion.

No objections.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 3:16 PM

Post #15 of 22 (194 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 01:17 PM, David Daney wrote:
>
> I usually see exception table sizes on the order of 2^10 entries, so I
> have to wonder how much you really gain from an O(1) implementation.
>

One thing that probably would give more of a boost is to use a rbtree or
similar structure to figure out *which* extable (if any) we should be
looking at; right now it looks like we linearly walk the modules, and
don't even look to see if we are inside that module before we do a
bsearch in that module's extable...

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tony.luck at gmail

Apr 19, 2012, 3:47 PM

Post #16 of 22 (201 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 3:16 PM, H. Peter Anvin <hpa [at] zytor> wrote:
> One thing that probably would give more of a boost is to use a rbtree or
> similar structure to figure out *which* extable (if any) we should be
> looking at; right now it looks like we linearly walk the modules, and
> don't even look to see if we are inside that module before we do a
> bsearch in that module's extable...

How many entries are in the extable for a typical module? Perhaps it might
make sense to bundle them all into one sorted combined table? Of course
you would have to have a way to squeeze them back out of the combined
table at module unload time.

This moves the cost to module load/unload time ... which is hopefully rare
compared to table lookup.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Apr 19, 2012, 3:58 PM

Post #17 of 22 (195 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 3:47 PM, Tony Luck <tony.luck [at] gmail> wrote:
>
> How many entries are in the extable for a typical module? áPerhaps it might
> make sense to bundle them all into one sorted combined table? Of course
> you would have to have a way to squeeze them back out of the combined
> table at module unload time.
>
> This moves the cost to module load/unload time ... which is hopefully rare
> compared to table lookup.

Using a traditional chained hash-table might be very amenable to this
kind of situation. It's much easier to populate and doesn't have the
size issues. And realistically, we can probably size the hash table
for just the built-in kernel, because modules seldom have nearly as
many exception table entries, so adding them later to a fixed-size
table likely won't be too painful.

In fact, doing an "objdump" on the few modules I have, I didn't find a
*single* exception table entry. Maybe I did something wrong? Isn't it
the __ex_table in modules too?

(Admittedly, I avoid modules like the plague, so I don't tend to have
very many modules, and the ones I do have tend to be pretty limited.
So my module usage is absolutely not representative even if I think it
should be ;^).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 4:10 PM

Post #18 of 22 (196 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 03:58 PM, Linus Torvalds wrote:
>
> In fact, doing an "objdump" on the few modules I have, I didn't find a
> *single* exception table entry. Maybe I did something wrong? Isn't it
> the __ex_table in modules too?
>

It is, but I suspect a lot of modules don't end up with any exception
table entries, as the common forms of user space access are out of line.

I suspect that just finding the module we're in or not in before
searching its ex_table is probably good enough, but a global hash would
be better. That being said, some distros are complaining about the
amount of time it takes to load modules on boot...

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tony.luck at gmail

Apr 19, 2012, 4:26 PM

Post #19 of 22 (191 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 4:10 PM, H. Peter Anvin <hpa [at] zytor> wrote:
> be better. áThat being said, some distros are complaining about the
> amount of time it takes to load modules on boot...

That could be fixed in the installer for the distribution by rebuilding a kernel
with the target set of modules for the system built in.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

Apr 19, 2012, 4:35 PM

Post #20 of 22 (192 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On 04/19/2012 04:26 PM, Tony Luck wrote:
> On Thu, Apr 19, 2012 at 4:10 PM, H. Peter Anvin <hpa [at] zytor> wrote:
>> be better. That being said, some distros are complaining about the
>> amount of time it takes to load modules on boot...
>
> That could be fixed in the installer for the distribution by rebuilding a kernel
> with the target set of modules for the system built in.
>

... assuming you have a well-defined "the system". It isn't always you
will boot on the same hardware every time.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


schwab at linux-m68k

Apr 20, 2012, 1:26 AM

Post #21 of 22 (178 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

Tony Luck <tony.luck [at] gmail> writes:

> On Thu, Apr 19, 2012 at 4:10 PM, H. Peter Anvin <hpa [at] zytor> wrote:
>> be better.  That being said, some distros are complaining about the
>> amount of time it takes to load modules on boot...
>
> That could be fixed in the installer for the distribution by rebuilding a kernel
> with the target set of modules for the system built in.

Which would also make it pretty much unsupportable.

Andreas.

--
Andreas Schwab, schwab [at] linux-m68k
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at amd64

Apr 20, 2012, 1:46 AM

Post #22 of 22 (177 views)
Permalink
Re: [PATCH 3/3] x86, extable: Handle early exceptions [In reply to]

On Thu, Apr 19, 2012 at 11:11:00AM -0700, Linus Torvalds wrote:
> > OTOH, if we can share early and normal exception handling lookup code, then a
> > perfect hash would make sense as those exceptions would pile up.
>
> Oh, any of this only makes sense if we can share it with the runtime
> exception lookup.
>
> They are *seldom* hugely performance-critical, but there are some
> unusual loads where you do get a fair number of exceptions.

I was thinking, and this is probably purely hypothetical and tangential
to the topic but, what happens if we get an exception right in the
middle between using the early_idt_handler's and switching to the normal
trap handlers in trap_init()?

write_idt_entry() is a simple memcpy so what happens if we have a
half-written descriptor? Won't we need some locking there to atomize the
switch?

Or am I dreaming?

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.