Update README.md (#698)

docs/release/0.7/README.md

@@ -40,7 +40,7 @@ To address this, we analysed what was doing while holding the lock.
 We found that we were doing a several things that were causing more time to be spent inside the lock than was necessary.
 Overall, we improve the start-up time of `snmalloc` in high thread scenarios as follows:
 
-We have a particularly tough benchmark for testing [startup time](../src/test/perf/startup/startup.cc).
+We have a particularly tough benchmark for testing [startup time](../../../src/test/perf/startup/startup.cc).
 We used a machine with 72 hardware threads.
 The benchmark causes all the threads to synchronise on starting their first allocation.
 This means all 72 threads are contending on the lock at the same time to get their allocator initialised.
@@ -121,7 +121,7 @@ It does not increase the size of the pagemap.
 
 We have built a simple example inspired by Google's `miracle_ptr`,
 that uses this feature to provide the reference counting for all allocations, but out-of-band.
-See [miracle_ptr](../src/test/func/miracle_ptr/miracle_ptr.cc) for our current experiment.
+See [miracle_ptr](../../../src/test/func/miracle_ptr/miracle_ptr.cc) for our current experiment.
 We are still experimenting with this feature, and would love to hear your feedback.
 
 ## Conclusion