>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 10.06.09 16:51 >>>
>> >+ unsigned long *preswap_map;
>> >+ unsigned int preswap_pages;
>>
>> Missing #ifdef CONFIG_PRESWAP?
>
>I had one there in an earlier draft but it causes more
>ifdef's elsewhere. Since swap_info_struct is so rarely
>instantiated (one per swap device), I thought maybe
>avoiding additional ifdef's might be more attractive
>than saving a few bytes system-wide. Thoughts?
Of course in the end it's up to you, but in our kernels we're trying to keep
the native kernel as unaffected as possible, which means that conditonals
should be where-ever code is added without abstracting macros/inline
functions which would expand to nothing in native.
>> >+static inline void *preswap_malloc(unsigned long size)
>> >+{
>> >+ return vmalloc(size);
>>
>> I would view this as problematic on 32-bit, as the vmalloc
>> space is rather
>> restricted there. Not because the allocation here may fail,
>> but because it
>> may cause failures elsewhere. Some feedback on the amount of vmalloc
>> space used and/or still available is going to be needed here
>> I'd think.
>
>The swapmap requires one byte vmalloc'ed for every page
>in every swap device. Preswap_map requires one additional
>bit to be vmalloc'ed for every swapmap byte. Is this
Okay, I thought I saw it to be a pointer per page. In any case, the question
is how large a swap file is "reasonable" on 32-bits, and what consequences
exceeding "reasonable" would have. In any case, the supported limit is
4G pages afair, and having a swap file anywhere in the tens or hundreds of
Gb range could become a problem. But I agree that this may be more a
theoretical issue, since such configurations should rather use 64-bit setups.
>likely to be a problem then? By "some feedback", do
>you mean I should add a comment?
No, I really meant feedback from the vmalloc allocator.
>I noticed in recent kernel versions that swap_list has
>seemed to bounce back and forth between static and non-static.
>It isn't clear to me if this is for data-hiding or just because
>someone noticed it wasn't being used in other source files.
>
>I thought about adding list-walking macros, but it seemed
>a bit extreme just to avoid extern-ifying a single static.
>
>In any case, unless you object, I'd like to leave this
>as is for 2.6.18-xen but I do expect some feedback and
>possible changes when proposing it upstream. (And for
>upstream, I'd rather start with a cleaner diffstat, then
>move chunks of code to swapfile.c in response to maintainer
>feedback :-)
As above, it's your choice, but will make integrating this into our kernels
mode difficult (until there's a production ready pv-ops based kernel that
we could leverage).
>> >+config TMEM
>> >+ bool "Transcendent memory support"
>> >+ def_bool y
>> >+ depends on XEN
>> >+ help
>> >+ In a virtualized environment, allows unused and underutilized
>> >+ system physical memory to be made accessible through a narrow
>> >+ well-defined page-copy-based API. If unsure, say Y.
>>
>> 'bool' followed by 'def_bool'? And even more, an experimental
>> (as I would
>> view it at this stage) feature that defaults to 'yes'?
>
>I have to admit complete bafflement at Kconfig syntax. It
>seems I can never get it right. (Is there a good README
>someplace that I can learn from?)
I've never seen one other than Linux'
Documentation/kbuld/kconfig-language.txt (which likely isn't what you're
after).
>It would certainly never default to 'yes' upstream, but I
>thought it might be OK in 2.6.18-xen, especially since it
>does essentially nothing if Xen doesn't have tmem (or if
>it has it but it is not enabled).
>
>If 'no' is best, what's the best Kconfig syntax for that?
>(I tried changing "def_bool y" to "def_bool n" once and
>it didn't make any difference!)
>
>> Also, does have selecting TMEM on its own any meaning? If not (which I
>> think is the case), then 'select'ing TMEM from the other two
>> options may
>> be more appropriate (while TMEM then shouldn't have a prompt anymore).
>
>I am anticipating other kernel uses for tmem, though what
>you suggest makes sense (if I could figure out the Kconfig
>syntax to do it! :-)
Here a completely untested suggestion:
#
# support for transcendent memory
#
config TMEM
bool
config PRECACHE
bool "Cache clean pages in transcendent memory"
depends on XEN
select TMEM
help
Allows the transcendent memory pool to be used to store clean
page-cache pages which, under some circumstances, will greatly
reduce paging and thus improve performance. If unsure, say Y.
config PRESWAP
bool "Swap pages to transcendent memory"
depends on XEN
select TMEM
help
Allows the transcendent memory pool to be used as a pseudo-swap
device which, under some circumstances, will greatly reduce
swapping and thus improve performance. If unsure, say Y.
(whether you'd want to keep the help previously associated with TMEM is a
matter of taste - an option without prompt has no way to ever display its
help text, so it would just serve documentation purposes in the Kconfig file
itself).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home