From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 7EBDA3846027 for ; Thu, 3 Jun 2021 10:37:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7EBDA3846027 Received: by mail-pl1-x629.google.com with SMTP id 11so2641190plk.12 for ; Thu, 03 Jun 2021 03:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Kfg8rXB0IROk/UI6QThRe+rNVeBpQwMVKaMiZFdhWeQ=; b=rrDz6B7MMrVAEXNpgbLbrYMIz4WEtz84CayhiiEgfYUx6IH0KkpWwf+kh/h8Qx1ocL ep5vmx/ie4OVxSGSVvuVkc6GDNC7ONZsn5Brh+Vj/eBUM2o43Jse8cxSZLPSs7S2yBHl 7lLCjL0ljj325RIwlkhsDxpZlZarBbKv52EcaIhUi2d8+ReLNPipziH1LysRVmGOVl4m 8zZP9oZnvQ/M6DpqjULIgochCo+hnKYpS2S7eEYLtnPK1svfezVY9ODU0rPsDvOEn5Dc L9WzgFWUuueKM7WYvRai2YDbd8zTY0hWMsOtFg3x1nKBK/5IeKYEDVROoIft+p8edVwU ZVwA== X-Gm-Message-State: AOAM531LMgP9L5X8POLs9npShuKJLUPI8UZ/1lX6KzXt/S21epKCXz9y UcobyP8I5hd06XcKvGUfExE= X-Google-Smtp-Source: ABdhPJzGGzSnSpU4Nfc6S8rmSBnz7YZsTx98nOAazViDrITg/BCdb24fWLMzyfjfjVrsF83xgdHUmA== X-Received: by 2002:a17:902:db01:b029:f6:4a13:1764 with SMTP id m1-20020a170902db01b02900f64a131764mr35417320plx.25.1622716664461; Thu, 03 Jun 2021 03:37:44 -0700 (PDT) Received: from localhost (g176.222-224-212.ppp.wakwak.ne.jp. [222.224.212.176]) by smtp.gmail.com with ESMTPSA id e6sm2126494pjl.3.2021.06.03.03.37.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Jun 2021 03:37:43 -0700 (PDT) Date: Thu, 3 Jun 2021 19:37:41 +0900 From: Stafford Horne To: Adhemerval Zanella Cc: GLIBC patches Subject: Re: GLIBC Localedata out of memory Message-ID: References: <20210130235020.GE2002709@lianli.shorne-pla.net> <36a492ba-facf-0745-b6f5-772e1a45f51f@linaro.org> <20210202214034.GJ2002709@lianli.shorne-pla.net> <4fdb07b3-c830-828e-bb47-4488bab6bd28@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fdb07b3-c830-828e-bb47-4488bab6bd28@linaro.org> X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 10:37:47 -0000 On Tue, Jun 01, 2021 at 02:45:47PM -0300, Adhemerval Zanella wrote: > > > On 29/05/2021 07:08, Stafford Horne wrote: > > On Wed, Feb 03, 2021 at 06:40:34AM +0900, Stafford Horne wrote: > >> On Tue, Feb 02, 2021 at 10:40:02AM -0300, Adhemerval Zanella wrote: > >>> > >>> > >>> On 30/01/2021 20:50, Stafford Horne via Libc-alpha wrote: > >>>> Hello, > >>>> > >>>> I am working on testing the new OpenRISC port and getting all of the tests > >>>> passing. I am having an issue with generating localedata on my board running > >>>> out of memory. The process is getting killed by the linux oom-killer. The > >>>> board has 256mb ram and it seems to not be enough. Lot's of ram is being used > >>>> by my rootfs. > >>> > >>> I usually ran a full make check on a sh4 board that has 512MB of ram and it is > >>> shared with debian buildd process and I haven't see any issue. The machine does > >>> have 8GBi of swap enabled, so it might be mitigated by this. > >>> > >>> I checked the memory requirements of localedata generation (using valgrind massig) > >>> for tests and it seems that only one (cmw_TW.UTF8) consumes about ~190MB, mostly > >>> uses about ~150MB (as below). So I think using a small swap should help you here. > >>> > >>> az_AZ.UTF-8 : 143.4 MB > >>> bg_BG.UTF-8 : 145.29 MB > >>> am_ET.UTF-8 : 145.62 MB > >>> ber_DZ.UTF-8 : 145.28 MB > >>> ber_MA.UTF-8 : 145.26 MB > >>> be_BY.UTF-8 : 145.27 MB > >>> br_FR.UTF-8 : 145.26 MB > >>> bs_BA.UTF-8 : 145.27 MB > >>> ckb_IQ.UTF-8 : 144.6 MB > >>> cmn_TW.UTF-8 : 190.72 MB > >> > >> Actually, I was able to get the locale generation working yesterday by shrinking > >> my rootfs as much as possible. Next I found that the sort-test is failing > >> (localedata/xfrm-test with -nocache). The -nocache option makes the program > >> allocate 4096 byte per each locale line to avoid strxfrm from using a cache > >> path. Oh boy! > >> > >>>> > >>>> Previously I was running tests on a simulator where I could adjust the ram to > >>>> anything I like. But now I am running tests on my ARTY fpga dev board. > >>>> > >>>> Is it OK to skip locale generation in tests results? Or any suggestions? > >>> > >>> You will need the locales to get a full result, otherwise some tests will > >>> fail. I think it should be possible to build a native localedef and > >>> generate the locales in the host for a cross-compilation. You will need to > >>> handle the possible endianess mismatch though and there is the potential > >>> issue of a conversion library not support by the host that test might use. > >> > >> I think that I'm going to need to solve the ram issue by giving it some swap. > >> > >> I tried swap over NFS but that resulted in write errors (Write error on dio > >> swapfile): > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/page_io.c?h=v5.11-rc6#n351 > >> > >> I will try to use an SD card. > > > > So, this took a bit longer than I expected but I have swap working now over SD > > card and I don't have a memory issue any more generating locale data. > > > > Interesting chain of events: > > - Had to order SD card pmod for my board which took a few days > > - Next, I found my SoC had broken hardware (ok its FPGA, but it took about > > a month to fix.) > > - After fixing we found some issues with the kernel driver, but now those > > are fixed and everyting works fine. > > - My workstation died so I had to rebuild it, now I have a fancy 6 core > > processor. > > > > Anyway, another question. Do most glibc embedded developers build and run tests > > on embedded boards using a cross-compiler and 'scripts/cross-test-ssh.sh'? > > I usually run it natively, but I think both recent ports for arc and riscv32 > were done using the scripts/cross-test-ssh.sh. Thanks, its good to know. I will update the wiki with these details: - https://sourceware.org/glibc/wiki/Testing/Testsuite#Testing_with_a_cross-compiler > > > > I have been running tests like this using a buildroot rootfs on my board. > > > > I now have 58 failures, but looking into them some seem related to handling of > > stdout and it seems like maybe its related to running over SSH. > > > > If this is what other are doing then I will continue with SSH and figure out > > these issues. But if other do another way, i.e. with a native compiler on > > the board then I will look into that. In that case I will probably have to > > start building debian for fedora as buildroot doesn't allow for creating > > a native compiler. > > Usually the issues reported for bring up and newer architectures are: > > - Tests timeout. A lot of tests are build and set to run on faster > machine, so they might timeout on slower ones. I would recommend > to run the testsuite with TIMEOUTFACTOR environment variable set > to 10 or something higher (it might extend the make check if the > test is stuck due some failure). I have sored this one, but it could be that some of the 58 failures are still just timeouts. > - Missing installed library, either libgcc_s.so or libstdc++.so. > The former is required for stack unwind required for some pthread > routines while the latter for testing. I would recommend to > copy both of them to the build directory prior ran the testsuite. Yup, I have sorted this one out. > - Issues with file permission or synchronization issues depending of > the filesystem. If I recall correctly NFS might not implement all > the required facilities depending of the version used. I am not > sure how to mitigate it. Thanks. Thanks for the notes.