Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1324757 > unrolled thread

Re: [RFC v1 0/8] x86/init: Linux linker tables

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v1 0/8] x86/init: Linux linker tables "H. Peter Anvin" <hpa@zytor.com> - 2016-02-03 01:30 +0100
    Re: [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-03 01:30 +0100
      Re: [RFC v1 0/8] x86/init: Linux linker tables "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-02-03 01:50 +0100

#1324757 — Re: [RFC v1 0/8] x86/init: Linux linker tables

On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>
>> Should it be possible to resuse free_init_pages() and/or
>> free_reserved_area() only for routines (members in the array in this
>> case of a struct of fns) that don't meet our subarch once we're done
>> iterating over the routies and know we can discard things we know we
>> can drop? Through a cursory glance, *I think* its possible as-is, we
>> would just need easy access to the respective start and end addresses
>> and I guess there lies the challenge. Question is, is would that be
>> clean enough for us? Or are there other things you can think of that
>> perhaps might make this prospect cleaner later to add?
>>
>> I figure better ask now for architectural purposes than later after merged.
> 
> I don't think its needed we iron out in a solution *now* to be able to
> free code we know we won't need at run time but having a solid
> understanding adding this feature later without much impact to users
> might be worthy. As such I was pursuing a very basic proof of concept
> to ensure this is possible first given I didn't hear back if folks
> were sure this might be possible. I don't think a proof of concept
> should take long so just want to get fleshed out.
> 

This applies to the specific subarch use rather than generic linker
tables, right?

	-hpa

[toc] | [next] | [standalone]

#1324758

On Tue, Feb 2, 2016 at 4:25 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>>
>>> Should it be possible to resuse free_init_pages() and/or
>>> free_reserved_area() only for routines (members in the array in this
>>> case of a struct of fns) that don't meet our subarch once we're done
>>> iterating over the routies and know we can discard things we know we
>>> can drop? Through a cursory glance, *I think* its possible as-is, we
>>> would just need easy access to the respective start and end addresses
>>> and I guess there lies the challenge. Question is, is would that be
>>> clean enough for us? Or are there other things you can think of that
>>> perhaps might make this prospect cleaner later to add?
>>>
>>> I figure better ask now for architectural purposes than later after merged.
>>
>> I don't think its needed we iron out in a solution *now* to be able to
>> free code we know we won't need at run time but having a solid
>> understanding adding this feature later without much impact to users
>> might be worthy. As such I was pursuing a very basic proof of concept
>> to ensure this is possible first given I didn't hear back if folks
>> were sure this might be possible. I don't think a proof of concept
>> should take long so just want to get fleshed out.
>>
>
> This applies to the specific subarch use rather than generic linker
> tables, right?

Well both, given that for instance the kernel frees unused kernel code
using the __init section, so a neat generic section solution for this
perhaps in consideration for the subarch might be worthy to consider.
You had also suggested perhaps the linker table could be pivoted based
on the subarch at one point too, so I gave that a though. It would
make the freeing much easier but for run time it wouldn't fit well
into the current design yet.

 Luis

[toc] | [prev] | [next] | [standalone]

#1324787

On Tue, Feb 2, 2016 at 4:28 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, Feb 2, 2016 at 4:25 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>s>>
>>>> Should it be possible to resuse free_init_pages() and/or
>>>> free_reserved_area() only for routines (members in the array in this
>>>> case of a struct of fns) that don't meet our subarch once we're done
>>>> iterating over the routies and know we can discard things we know we
>>>> can drop? Through a cursory glance, *I think* its possible as-is, we
>>>> would just need easy access to the respective start and end addresses
>>>> and I guess there lies the challenge. Question is, is would that be
>>>> clean enough for us? Or are there other things you can think of that
>>>> perhaps might make this prospect cleaner later to add?
>>>>
>>>> I figure better ask now for architectural purposes than later after merged.
>>>
>>> I don't think its needed we iron out in a solution *now* to be able to
>>> free code we know we won't need at run time but having a solid
>>> understanding adding this feature later without much impact to users
>>> might be worthy. As such I was pursuing a very basic proof of concept
>>> to ensure this is possible first given I didn't hear back if folks
>>> were sure this might be possible. I don't think a proof of concept
>>> should take long so just want to get fleshed out.
>>>
>>
>> This applies to the specific subarch use rather than generic linker
>> tables, right?
>
> Well both, given that for instance the kernel frees unused kernel code
> using the __init section, so a neat generic section solution for this
> perhaps in consideration for the subarch might be worthy to consider.
> You had also suggested perhaps the linker table could be pivoted based
> on the subarch at one point too, so I gave that a though. It would
> make the freeing much easier but for run time it wouldn't fit well
> into the current design yet.

OK so I've decided that to make the Proof of Concept also immediately
useful I could try to convert one of the *existing* ad hoc
link tables to generic using this new solution. The POC will not be
required as part of the patch series, just knowing it works is all
that would be needed.

To be clear then what I'll do:

  * I'll be respinning this series *now* to incorporate all feedback
given but *will not post* until I also have a proof of concept of a
conversion done and tested that includes free unused code
  * Since the renaming paravirt_enabled() patches are separate but
folks agree with them I'll submit that as an independent series,
shortly
  * Since the patch x86/boot: add BIT() to boot/bitops." is
independent I'll submit as independent single patch, shortly

 Luis

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web