git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Fast access git-rev-list output: some OS knowledge required

From
MCMarco Costalba <mcostalba@gmail.com>
Date
Dec 7, 2006, 06:46 UTC
Message-ID
<e5bfff550612062246m194ce235nf97149f8b041f486@mail.gmail.com>
In-Reply-To
<Pine.LNX.4.64.0612061642440.3542@woody.osdl.org>
On 12/7/06, Linus Torvalds <torvalds@osdl.org> wrote:
Show 13 quoted lines
>
>
> On Thu, 7 Dec 2006, Johannes Schindelin wrote:
> >
> > Because, depending on what you do, the revision machinery is not
> > reentrable. For example, if you filter by filename, the history is
> > rewritten in-memory to simulate a history where just that filename was
> > tracked, and nothing else. These changes are not cleaned up after calling
> > the internal revision machinery.
>
> Well, it really wouldn't be that hard to add a new library interface to
> "reset object state". We could fairly trivially either:
>
So the library approach sounds like the best?

Of course in this case the producer git-rev-list and the receiver use the same address space.

In the case of a temporary file data is first copied to OS disk cache buffers and then again to userspace, in qgit address space. But the real pain is that the temporary file is always flushed to disk after 4-5 seconds from creation, also if under heavy read/write activity. This is a problem for big repos. I really don't know how to workaround this useless disk flush.

Finally, what about using some kind of shared memory at run time, instead of _sharing_ developer libraries ;-) ? is it too messy?

Probably the concurrent reading while writing is possible without syncro if the reader understands that a sequence of _two_ or more \0 it means the end of current write stream if producer is still running or the end of data if producer is not running anymore. I use a similar approach in the 'temporary file' patch where receiver is able to read while producer writes without explicit synchronization. In that case a read() of a block smaller then maximum with producer still running is used as the 'break' condition in the receiver while loop.

Previous: Linus Torvalds
Message 17 of 17 in “Fast access git-rev-list output: some OS knowledge required”
  1. Marco CostalbaDec 6, 2006
  2. Shawn PearceDec 6, 2006
  3. Marco CostalbaDec 6, 2006
  4. Shawn PearceDec 6, 2006
  5. Shawn PearceDec 6, 2006
  6. Marco CostalbaDec 6, 2006
  7. Shawn PearceDec 6, 2006
  8. Andreas EricssonDec 7, 2006
  9. Johannes SchindelinDec 7, 2006
  10. Andreas EricssonDec 7, 2006
  11. Johannes SchindelinDec 7, 2006
  12. Marco CostalbaDec 8, 2006
  13. Michael K. EdwardsDec 8, 2006
  14. Marco CostalbaDec 9, 2006
  15. Johannes SchindelinDec 6, 2006
  16. Linus TorvaldsDec 7, 2006
  17. Marco CostalbaDec 7, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.