[dpdk-dev] [PATCH v3 0/4] no-huge unit test

[Aaron Conole]

Ruifeng Wang <Ruifeng.Wang at arm.com> writes:

>> -----Original Message-----
>> From: David Marchand <david.marchand at redhat.com>
>> Sent: Friday, March 13, 2020 23:54
>> To: Aaron Conole <aconole at redhat.com>
>> Cc: Ruifeng Wang <Ruifeng.Wang at arm.com>; Michael Santana
>> <maicolgabriel at hotmail.com>; Bruce Richardson
>> <bruce.richardson at intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev at intel.com>; Cristian Dumitrescu
>> <cristian.dumitrescu at intel.com>; Wang, Yipeng1
>> <yipeng1.wang at intel.com>; Gobriel, Sameh <sameh.gobriel at intel.com>;
>> dev <dev at dpdk.org>; Burakov, Anatoly <anatoly.burakov at intel.com>;
>> Gavin Hu <Gavin.Hu at arm.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli at arm.com>; juraj.linkes at pantheon.tech; nd
>> <nd at arm.com>
>> Subject: Re: [PATCH v3 0/4] no-huge unit test
>> 
>> On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole at redhat.com> wrote:
>> >
>> > Aaron Conole <aconole at redhat.com> writes:
>> >
>> > > Ruifeng Wang <ruifeng.wang at arm.com> writes:
>> > >
>> > >> For environments (such as containers) where hugetlbfs are not
>> > >> available, some unit tests can be run with 'no-huge' option.
>> > >>
>> > >> fast-tests suites is generated dynamically according to hugetlbfs
>> > >> availability in building environment. This allows unit test to run
>> > >> in different environments using the same suite name.
>> > >>
>> > >> Several test cases are fixed to be able to run in no-huge mode.
>> > >
>> > > This looks great!  Thanks, Ruifeng.
>> > >
>> > > I'm going to ack it once I see it run under the robot :)
>> >
>> > Just looking through the robot's run, it seems that on the statically
>> > linked Arm64 build, the disk quota is getting exceeded.  Do we need to
>> > request some more disk quota for this somehow?  Is the build getting
>> > too large?
>> 
>> It seems to repeat.
>> https://travis-ci.com/github/ovsrobot/dpdk/jobs/297840285#L2975
>> 
>> Do you know how much space we have in travis?
>> Is the (c?)cache getting too big?
>
> Yes, it is probably caused by cache.
> I hit the disk quota issue as well when running Travis against the latest Master code.
> After deleting caches, the issue was gone. Then Travis run with this
> series of patches also got a pass.
>
> Hi Aaron,
> Is is OK to clear cache of robot and re-run the build?

I can do this, but I am concerned that we will need to disable the cache
to avoid this error on a consistent basis.

> Thanks.
> /Ruifeng
>
>> You can find out the per job cache size via the travis cli.
>> 
>> 
>> --
>> David Marchand