Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On 11/20/2011 03:28 PM, David Woodhouse wrote: > On Sun, 2011-11-20 at 15:26 -0800, H. Peter Anvin wrote: >> If we're going to do this at build time, I would suggest using a >> collisionless hash instead. The lookup time for those are O(1), but >> they definitely need to be done at build time. > > Is the lookup time really an issue? > Probably not a big one (in most scenarios), but with better exception handling it might stretch the usability of exceptions. The bigger thing is that once you're doing a build-time special handler for this *anyway*, you might as well drive the cost of the lookup to functionally zero. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Sun, 2011-11-20 at 15:26 -0800, H. Peter Anvin wrote: > If we're going to do this at build time, I would suggest using a > collisionless hash instead. The lookup time for those are O(1), but > they definitely need to be done at build time. Is the lookup time really an issue? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On 11/20/2011 03:26 PM, H. Peter Anvin wrote: > On 11/18/2011 11:37 AM, David Daney wrote: >> From: David Daney >> >> Using this build-time sort saves time booting as we don't have to burn >> cycles sorting the exception table. >> > > If we're going to do this at build time, I would suggest using a > collisionless hash instead. The lookup time for those are O(1), but > they definitely need to be done at build time. > I have some code for generating these kinds of tables, they just need to be hooked up. I will dig it up later today or tomorrow. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On 11/18/2011 11:37 AM, David Daney wrote: > From: David Daney > > Using this build-time sort saves time booting as we don't have to burn > cycles sorting the exception table. > If we're going to do this at build time, I would suggest using a collisionless hash instead. The lookup time for those are O(1), but they definitely need to be done at build time. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Friday 18 November 2011 14:37:44 David Daney wrote:
> --- /dev/null
> +++ b/scripts/sortextable.c
>
> +/*
> + * sortextable.c: Sort the kernel's exception table
> + *
> + * Copyright 2011 Cavium, Inc.
> + *
> + * Based on code taken from recortmcount.c which is:
seems like it'd be nice if the duplicate helper funcs were placed in a common
header file rather than copying & pasting between them.
> + switch (w2(ehdr->e_machine)) {
> + default:
> + fprintf(stderr, "unrecognized e_machine %d %s\n",
> + w2(ehdr->e_machine), fname);
> + fail_file();
> + break;
> + case EM_386:
> + case EM_MIPS:
> + case EM_X86_64:
> + break;
> + } /* end switch */
unlike recordmcount, this file doesn't do anything arch specific. so let's
just
delete this and be done.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH RFC 0/5] Speed booting by sorting exception tables at build time.
On Friday 18 November 2011 14:37:43 David Daney wrote: > I noticed when booting MIPS64 kernels that sorting of the main > __ex_table was taking a long time (2,692,220 cycles or 3.3 mS at > 800MHz to be exact). That is not too bad for real silicon > implementations, but when running on a slow simulator, it can be > significant. i've seen this perf hit in my simulation runs too > Here is more or less what I did: > > o A flag word is added to the kernel to indicate that the __ex_table > is already sorted. sort_main_extable() checks this and if it is > clear, returns without doing the sort. > > o I shamelessly stole code from recordmcount and created a new build > time helper program 'sortextable'. This is run on the final vmlinux > image, it sorts the table, and then clears the flag word. > > Potential areas for improvement: > > o Sort module exception tables too. > > o Get rit of the flag word, and assume that if an architecture supports > build time sorting, that it must have been done. > > o Add support for architectures other than MIPS and x86 i don't see much here that is arch-specific. why have a knob at all ? let's just jump in with both feet and do this for everyone :). -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH RFC 3/5] kbuild/extable: Hook up sortextable into the build system.
On 18.11.2011 20:37, David Daney wrote: > + $(if $(CONFIG_BUILDTIME_EXTABLE_SORT), \ > + $(Q)$(if $($(quiet)cmd_sortextable),\ > + echo ' $($(quiet)cmd_sortextable) vmlinux' &&) \ > + $(cmd_sortextable) vmlinux) Why do you opencode $(call cmd,sortextable) here? Michal -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
