Kernel config for 5.0

[Rich]

Hi curaga
I think he's referring to those secret hidden options in the kernel config file that when enabled make it
run 3 times faster.

[Zendrael]

What do you mean?

I was thinking in something like this: http://www.performancewiki.com/linux-tuning.html

I believe that it is already done, if not, maybe could be useful (or not).

Will study more of the kernel on Core.

[tinypoodle]

Hi curaga
I think he's referring to those secret hidden options in the kernel config file that when enabled make it
run 3 times faster.

like

Code: [Select]

CONFIG_HAS_TURBO_MODE=y?

[tinypoodle]

What do you mean?

I was thinking in something like this: http://www.performancewiki.com/linux-tuning.html

What exactly of all of those would you want to see implemented on kernel config level?

[gerald_clark]

Compiling in large values for runtime tuneable values wastes memory for the majority of users who are running on minimal hardware.
If you really think you are going to run a large, hi performance database and a high traffic webserver on your Tiny Core Linux, you can
always tune it up in bootlocal.sh.

[curaga]

It's been a bit over two weeks. Seems no changes to the original list.

Any requests made after this may still make it in time, but can't give a date.

[tinypoodle]

Code: [Select]

CONFIG_PCCARD=m
CONFIG_YENTA=m
Suggestion to consider changing those 2 from "m" to "y" to support earlier detection of storage devices attached through cardbus at boot.

[coreplayer2]

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68d929862e29a8b52a7f2f2f86a0600423b093cd

This patch is worth a mention because Linux has been said to brick some Samsung notebooks when writes consume more than 50% of NVRAM.   As first occurrences where reported, many peeps blamed the Linux kernel, however the fault has since been traced to the notebook's firmware.   AIUI the patch has been applied to the latest Linux kernel as a preventative measure.    I think it's worth considering for this build..

[coreplayer2]

AFAIK there is no configuration option in support "Secure Boot", the required tools it seems run before the boot-loader.  But would hate to be limited when a Secure Boot implementation is available by not having the correct supporting options available, am just not 100% sure is all

[curaga]

The secureboot signing infra is outside the scope of TC, and would require far too many changes. Will make sure the Samsung patch is included.

@tinypoodle:

Sure, will do.

[tinypoodle]

Great, thanks 

[coreplayer2]

Also Thanks

[serisman]

We're targeting 3.7 currently.

Can I ask why target 3.7 instead of 3.8?  According to kernel.org the 3.7 release is already end-of-life.

As for what additional to include (hopefully I am not too late already).

I would like to see the following added (the xf86 Nouveau driver is much better than the NV driver and requires this):
* CONFIG_DRM_NOUVEAU=m

and the following (for easier/faster hosting of tinycorelinux in a Hyper-V virtual machine):
* CONFIG_HYPERV_BALLON=m
* CONFIG_HYPERV_NET=m
* CONFIG_HYPERV_STORAGE=m
* CONFIG_HYPERV_UTILS=m
* CONFIG_HYPERV=m

[curaga]

Can I ask why target 3.7 instead of 3.8?  According to kernel.org the 3.7 release is already end-of-life.

3.8 had not matured enough at the time. It's just now getting there, so we're currently testing 3.8.4.

As for what additional to include (hopefully I am not too late already).

It is a bit too late, I'm afraid.


The nouveau driver is far too unstable to ship with confidence. The answer to that is the same as staging quality modules, welcome in the repo if contributed, but not included in the official build.

On HyperV support, since it was now out of staging, it was enabled for testing. Seems HYPERV_NET was missed as it would have needed going back, but it appears HyperV allows emulation of "normal" or legacy network cards too.

[serisman]

3.8 had not matured enough at the time. It's just now getting there, so we're currently testing 3.8.4.

Great.  That is the same kernel version I have been testing independently for a couple of days.  It has been working great on a low end Ivy Bridge based system.  It fixed all the stability issues I was having with the 3.0.21 kernel and actually lowered power consumption (watts) significantly.

It is a bit too late, I'm afraid.

No worries.

The nouveau driver is far too unstable to ship with confidence. The answer to that is the same as staging quality modules, welcome in the repo if contributed, but not included in the official build.

Well that helps to explain why I was having issues trying to get it to work (on my custom kernel / xf86 driver build) last night.  If I find a solution, I can contribute it if desired.

On HyperV support, since it was now out of staging, it was enabled for testing. Seems HYPERV_NET was missed as it would have needed going back, but it appears HyperV allows emulation of "normal" or legacy network cards too.

One thing to note, with the legacy NIC in Hyper-V one is limited to 100 mbps.  That is enough for some purposes, but sometimes one wants the extra bandwidth.  I can probably custom compile this for my purposes.

I think there is also a Hyper-V mouse driver that may be useful to some (myself included).  I can look it up later if needed.