Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: -tests Since when has it been failing: Unsure Testgrid link: Reason for failure: Unable to pre allocate 50x2MiB huge pages, probably due to memory pressure caused by kernel level caching. If requesting an substantial amount of huge page memory (like the tests), it is recommended to to it as early after boot as possible, or by using the kernel cmd line. Eg. this one: Anything else we need to know: will fix this issue, but in awaiting for that, we can just decrease the page count in the tests.
/sig node /cc derekwaynecarr
I think the reason of railure should be because a single hugepage of x86 is 2MiB as and a single page is 4KiB, not 2KiB.
Yes, is correct. Thanks for catching the typo :smile:
Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. This is probably because the kernel is caching a lot of stuff, making it hard for the kernel to fix it. Ill do some testing with dropping the caches (no user facing stuff will happen, only kernel level) before trying to pre allocate huge pages. /reopen
Reopened this issue. <detailsIn response to : Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
return pod } <del> // configureHugePages attempts to allocate 100Mi of 2Mi hugepages for testing purposes </del> <ins> // configureHugePages attempts to allocate 10Mi of 2Mi hugepages for testing purposes </ins> func configureHugePages() error { <del> err := exec.Command("/bin/sh", "-c", "echo 50 > /proc/sys/vm/nr_hugepages").Run() </del> <ins> err := exec.Command("/bin/sh", "-c", "echo 5 > /proc/sys/vm/nr_hugepages").Run() </ins> if err != nil { return err }

return err } e2elog.Logf("HugePages_Total is set to %v", numHugePages) <del> if numHugePages == 50 { </del> <ins> if numHugePages == 5 { </ins> return nil } <del> return fmt.Errorf("expected hugepages %v, but found %v", 50, numHugePages) </del> <ins> return fmt.Errorf("expected hugepages %v, but found %v", 5, numHugePages) </ins> } // releaseHugePages releases all pre-allocated hugepages

Limits: v1.ResourceList{ v1.ResourceName("cpu"):           resource.MustParse("10m"), v1.ResourceName("memory"):        resource.MustParse("100Mi"), <del> v1.ResourceName("hugepages-2Mi"): resource.MustParse("50Mi"), </del> <ins> v1.ResourceName("hugepages-2Mi"): resource.MustParse("6Mi"), </ins> }, }, },

}) podUID := string(pod.UID) ginkgo.By("checking if the expected hugetlb settings were applied") <del> verifyPod := makePodToVerifyHugePages("pod"+podUID, resource.MustParse("50Mi")) </del> <ins> verifyPod := makePodToVerifyHugePages("pod"+podUID, resource.MustParse("6Mi")) </ins> f.PodClient().Create(verifyPod) err := e2epod.WaitForPodSuccessInNamespace(f.ClientSet, verifyPod.Name, f.Namespace.Name) framework.ExpectNoError(err)

ginkgo.By("by waiting for hugepages resource to become available on the local node") gomega.Eventually(func() string { return pollResourceAsString(f, "hugepages-2Mi") <del> }, 30*time.Second, framework.Poll).Should(gomega.Equal("100Mi")) </del> <ins> }, 30*time.Second, framework.Poll).Should(gomega.Equal("10Mi")) </ins> }) runHugePagesTests(f)