search for: uncoalesc

...largest padding: 5/412/252927 Number of dead records: 2 Smallest/average/largest dead records: 399912712/661866360/923820008 Number of free records: 38999 Smallest/average/largest free records: 12/18485/715170720 Number of hash chains: 10000 Smallest/average/largest hash chains: 26/66/116 Number of uncoalesced records: 253 Smallest/average/largest uncoalesced runs: 1/1/2 Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes: 1/30/8/21/39/1/0 it ends with this error: tdb_recovery_allocate: overflow recovery area tdb_transaction_prepare_commit: failed to setup recovery data ../lib/tdb/com...

...Number of dead records: 2 > Smallest/average/largest dead records: 399912712/661866360/923820008 > Number of free records: 38999 > Smallest/average/largest free records: 12/18485/715170720 > Number of hash chains: 10000 > Smallest/average/largest hash chains: 26/66/116 > Number of uncoalesced records: 253 > Smallest/average/largest uncoalesced runs: 1/1/2 > Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes: > 1/30/8/21/39/1/0 > > > it ends with this error: > > tdb_recovery_allocate: overflow recovery area > tdb_transaction_prepare_commit:...

On 21/11/24 14:11, Dan Langille wrote: > On Wed, Nov 20, 2024, at 6:31 PM, Douglas Bagnall wrote: >> On 20/11/24 11:55, Dan Langille wrote: >> >>> Hope that helps. >> >> Not much unfortunately. >> >> Running this: >> >> net cache list >> >> will tell you what the cache thinks it contains. If it is filled with >> real

...ding: 13/25/106 > Number of dead records: 1 > Smallest/average/largest dead records: 823272/823272/823272 > Number of free records: 15 > Smallest/average/largest free records: 12/1420/20824 > Number of hash chains: 10000 > Smallest/average/largest hash chains: 0/1/8 > Number of uncoalesced records: 1 > Smallest/average/largest uncoalesced runs: 1/1/1 > Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes: 30/11/14/1/30/15/1 > root at filur01:/var/samba/cache # ls -l gencache.tdb > -rw-r--r-- 1 root wheel 2723840 Aug 30 10:54 gencache.tdb My guess woul...

...Oh, I see what you mean now. Doing such analysis would be useful for a thread block and not just a single thread but as you say you are onto something bigger than just a thread. We had published a short paper in ICS around this which uses polyhedral techniques to do such analysis and reason about uncoalesced access patterns in Cuda programs. You can find paper at https://dl.acm.org/doi/10.1145/2464996.2467288 On Sun, Aug 23, 2020, 11:00 PM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Ees, > > a while back we started a project with similar scope. > Unf...

On Wed, Aug 29, 2018 at 03:36:23PM +0200, Peter Eriksson via samba wrote: > For what it’s worth you are not alone in seeing similar problems with Samba and gencache. > > Our site has some 110K users (university with staff & students (including former ones), and currently around 2000 active (SMB) clients connecting to 5 different Samba servers (around 400-500 clients per server).

...0 Smallest/average/largest padding: 4/1528/19120 Number of dead records: 11146 Smallest/average/largest dead records: 416/2688/21816 Number of free records: 4049 Smallest/average/largest free records: 12/2579/6959332 Number of hash chains: 10007 Smallest/average/largest hash chains: 0/1/5 Number of uncoalesced records: 3473 Smallest/average/largest uncoalesced runs: 1/8/90 Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes: 0/1/3/25/70/1/0 (Around 120k users in AD, around 1600 concurrent SMB users right now (on the server where this data is from), but we see this even on single-user ser...

Upgraded to Samba 4.11.2 and I?ve now too started seeing the message: get_share_mode_lock: get_static_share_mode_data failed: NT_STATUS_NO_MEMORY A lot. I modified the source in source3/locking/share_mode_lock.c a bit in order to print out the values of the service path, smb_fname & old_write_time when it fails and it seems they are all NULL? [2019/11/14 14:24:23.358441, 0]

Hi all, As part of my research I want to investigate the relation between the grid's geometry and the memory accesses of a kernel in common gpu benchmarks (e.g Rodinia, Polybench etc). As a first step i want to answer the following question: - Given a kernel function with M possible memory accesses. For how many of those M accesses we can statically infer its location given concrete values