Hello, Roman.
>
> Hello, Uladzislau!
>
> Yeah, the version above looks much simpler!
> Looking forward for the next version of the patchset.
>
> Thanks!
Will upload it soon.
Thanks!
--
Vlad Rezki
On Tue, Mar 26, 2019 at 03:51:53PM +0100, Uladzislau Rezki wrote:
> Hello, Roman.
>
> > >
> > > So, does it mean that this function always returns two following elements?
> > > Can't it return a single element using the return statement instead?
> > > The second one can be calculated as ->next?
Hello, Roman.
> >
> > So, does it mean that this function always returns two following elements?
> > Can't it return a single element using the return statement instead?
> > The second one can be calculated as ->next?
> >
> Yes, they follow each other and if you return "prev" for example you
Hello, Roman!
> Hi, Uladzislau!
>
> Definitely a clever idea and very promising numbers!
>
> The overall approach makes total sense to me.
>
> I tried to go through the code, but it was a bit challenging.
> I wonder, if you can split it into smaller parts to simplify the review?
>
I
On Thu, Mar 21, 2019 at 08:03:27PM +0100, Uladzislau Rezki (Sony) wrote:
> Currently an allocation of the new vmap area is done over busy
> list iteration(complexity O(n)) until a suitable hole is found
> between two busy areas. Therefore each new allocation causes
> the list being grown. Due to
Currently an allocation of the new vmap area is done over busy
list iteration(complexity O(n)) until a suitable hole is found
between two busy areas. Therefore each new allocation causes
the list being grown. Due to over fragmented list and different
permissive parameters an allocation can take a
6 matches
Mail list logo
