Speed up trace mode (GSoC Project)

[Mihir Luthra]

> That's unfortunately not the same, since while you're swapping the
> second value, a different thread could swap the first for a different
> value again.
>

I get your point.
Generally what comes to the mind in such circumstances is blocking the
other thread some way like mostly by spin locks.
But at the same time, if I use spin locks here, there is no point of using
compare and swap.
So need to figure out a better solution to change variables staying with
cas.

>
> That should be possible using atomic fetch-and-add [1]. This may end up
> increasing the storage by more than we need, but that's not a problem.
>
> The problem I see is that we actually need to do the truncation and
> remapping at some point. We should end up in a situation where the size
> is actually larger than the file/memory block.
>

I understand. Many checks can be put to avoid this but at last they will
make the main reason of this code which is optimisation useless.


> Unfortunately ftruncate(2) is all that we have, and without writing
> kernel code I don't see a way to do this.
>

Actually I had kind of interpose to  __dt_ftruncate() and __dt_mmap in mind
that time. I should be more precise in words, sorry for that.
These would allow us to  make the checks beforehand but the same thing
again, doing so much would just erase the optimisation benefit we are
planning.
Although I am not sure about that because memory expansion would be
required very less if we predict to a good extent the memory required.


>
> Can you pastebin a main.log of a build that fails like this?
>

https://pastebin.com/FVdp4WTw

I guess now this was for some similar reason as path or co-existence.


>
>
> [1] https://en.wikipedia.org/wiki/Fetch-and-add
>
> Thanks.


Regards,
Mihir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190407/52dcbe7d/attachment.html>