Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible improvements to buffer pool #23

Open
ArnauPrat opened this issue Sep 20, 2018 · 1 comment
Open

Possible improvements to buffer pool #23

ArnauPrat opened this issue Sep 20, 2018 · 1 comment
Assignees

Comments

@ArnauPrat
Copy link
Contributor

ArnauPrat commented Sep 20, 2018

These are possible improvements to buffer pool:

  • Use a spinlock for the buffer descriptors or change atomic counters instead for m_referenceCount and m_usageCount (atomic counters would require rethinking the different operations un the buffer pool, see point 4)
  • Change the signature of unpin to accept a BufferHandler instead of a pageId_t. The handler already contains the bufferId_t of the buffer. Thus, we do not need to lock the partition to check the hash_table with the pid to bId mappings.
  • Use a pure array allocated with numa for the buffer descriptors. Since the array of descriptors is "static" (his size is set at initialization), we can just use a simple array.
  • Replace the map of page to bid for an unordered_map
  • (Optional as I am not even sure of it since it is very tricky) Rethink all the operations of the pool: pin, unpin, getEmptySlot, for performance opportunities (e.g. reduce the time a lock for a resource is acquired). For instance, the expensive operation (clock algorithm) that looks for a victim should not require the partition to be locked. It basically iterates over the descriptors in search of a victim and this can take a lot of cycles where other threads cannot pin anything on the partition. Once the victim is found (and the descriptor is properly locked, the reference count increased and unlocked), we lock the partition (the hash table) and update the entry. This way other threads can still look at the buffers hash table. This might require an additional check when a descriptor found in the table is locked by a thread, to recheck that the actual buffer descriptor actually contains the page that was requested and these was not evicted while looking in the hash table (note that getEmptySlot is not atomic anymore). Also a valid bit in the descriptor would be necessary to mark those pages with a reserved buffer slot but not yet ready (being read from the disk), so those threads looking for the same page can wait until the read finishes.
  • Of course, measure any change
@ArnauPrat
Copy link
Contributor Author

Also, for the hash table lock (current partition lock), one could use a read/write lock (allowing multiple readers - one single writer)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants