On 01.12.14 13:44, [email protected] wrote: > I've recently run into an issue where the vrouter module fails to get > loaded during our node bootstrapping process, erring out with a "Cannot > allocate memory" error. > > I eventually tracked it down to the fact that vrouter attempts to grab > quite a lot of contiguous memory pages, which simply aren't available on > the systems I'm bootstrapping at the time when I'm trying to load the > module. > > get_free_pages acquires contiguous memory pages in powers of 2. A > 0-order allocation is just a single page. A 1-order allocation is 2 > pages, 2-order 4 pages, etc. 10-order is 1024 pages. > > With the defaults, loading the vrouter module requires: > > 1 2-order allocation > 1 3-order allocation > 1 4-order allocation > 2 5-order allocations > 1 7-order allocation > 1 9-order allocation > 8 10-order allocations > > I often only have 1-3 10-order allocations available (as reported in > /proc/buddyinfo). > > A reboot fixes this, since the vrouter module gets loaded quite early in > the boot process, but I'd really rather not have to reboot as part of my > bootstrapping process. > > I tried reducing VR_SINGLE_ALLOC_LIMIT to 4096*32 (i.e. preventing > anything above a 5-order allocation) which seems to fix this problem > entirely. > > Are there bad side effects to this that I haven't thought of? If not, > I'll just submit a patch for this. >
Hey Soren, did you fix that issue yet? It seems with our workaround (vm.min_free_kbytes: '1048576'), it still happens from time to time. (https://bugs.launchpad.net/opencontrail/+bug/1395134 is also still open) Regards, Stefan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
