From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by sourceware.org (Postfix) with ESMTPS id 0B6313959C39 for ; Tue, 1 Jun 2021 17:45:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B6313959C39 Received: by mail-qk1-x72a.google.com with SMTP id i67so15125494qkc.4 for ; Tue, 01 Jun 2021 10:45:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QKVhldoBuIYq41D/J3P/puHn715MzD/eHbetNlZ9SAU=; b=CdqKF2ucGTANP+wdEjUod1mAII/SuqzEKTULn/lfcJUrkxDp/PG6q0NBMC+ipkm1Sm BPCjHqWQmtdfMVcS26TJ6GsHz3joud8BjEvPJwDq0E0D4Q1AXm6/SlEkAmclsFJpMef8 M5Cm9OwaVWQ2Bcd6b3j2D8jUEFhqcD1HXkfG5WzXjv+psbgUnVD3XcYhFrB8QHOj5Hjk SRmMZvJXFISiQ2ZAorp0pf0ffd+fWKkRibPljmmk+4AymMMT3CCH89Y+8cK2n8oAX2Cq D9VEVQxCN+j2msSLYeHLe+1Midor8/xpXIA+fMzKPZ5d2auNqNwLZYHyXw9hD+ukV9Ne juVg== X-Gm-Message-State: AOAM530H33Yb/nyE1ljIUhhKNZZZlDerkzKmiLaQXjFOZfsOgAbIrsxL UpyKsotsIH+51Rl98q8qEG2FFxhCIvTN4Q== X-Google-Smtp-Source: ABdhPJyBv390hiU++QdtqCu1Ei80A4EP9SK4P131riE8HGIsAHRsmY4X/EcmiloNvfj5Pz229WTauA== X-Received: by 2002:a05:620a:2456:: with SMTP id h22mr22703969qkn.292.1622569550169; Tue, 01 Jun 2021 10:45:50 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id m10sm10568754qtq.62.2021.06.01.10.45.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Jun 2021 10:45:49 -0700 (PDT) Subject: Re: GLIBC Localedata out of memory To: Stafford Horne Cc: GLIBC patches References: <20210130235020.GE2002709@lianli.shorne-pla.net> <36a492ba-facf-0745-b6f5-772e1a45f51f@linaro.org> <20210202214034.GJ2002709@lianli.shorne-pla.net> From: Adhemerval Zanella Message-ID: <4fdb07b3-c830-828e-bb47-4488bab6bd28@linaro.org> Date: Tue, 1 Jun 2021 14:45:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Tue, 01 Jun 2021 17:45:52 -0000 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. > > 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). - 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. - 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.