On Thu, Nov 4, 2010 at 11:54 AM, Nikos Chantziaras <rea...@arcor.de> wrote: > On 11/04/2010 06:43 PM, Mark Knecht wrote: >> >> Hi, >> When starting VMware-Player I get the following message: >> >> The host's Linux kernel yield() functionality is disabled. >> Multiprocessor virtual machines exhibit degraded performance without >> yield(). Choose 'OK' to enable the sysctl 'kernel.sched_compat_yield' >> or 'Cancel' to continue without yield(). >> >> >> Looking around at VMware's site they recommend changing >> /etc/sysctl.conf to enable the feature: >> >> >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027987 >> >> I can do that but I'm pretty sure that if I edit that file then >> I'll lose the edits some day when doing etc-update's. > > Gentoo will never overwrite your /etc config files. New files are created > with an "._" prefix. When that happens, portage tells you that "N files in > /etc/ need updating." At that point, you either manually merge the changes > or use a tool like "dispatch-conf" (I recommend this one) or "etc-update". > And until you do so, the old files will be used.
Yes, thanks Nikos. I do understand that part. I tried dispatch-conf years ago and couldn't get the hang of it. It was not clear to me what was old/new and all the rest of that. My worry with etc-update is that I know, for the most part, all the files I modify when doing an install so I know what to look for when I'm selecting files to replace myself. However with that tool there's a point where you might have 20 files that need updating, you look at the list and nothing looks like what I changed and you hit -5 to tell it to do everything. I know I'm going to overwrite sysctl.conf that way because it's not in my mental list. It's easy enough for me to keep a copy and fix it by hand since the only place this option seems to matter is VMware and it's very clear about what the problem is. I'll likely just go that way. This isn't a problem that causes the machine not to boot or anything like that. Cheers, Mark
