search for: discontiguous

I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. And emitting discontiguous functions is a fundamental goal of this, right? On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thank...

...and we will follow up with this patch. > > Also for object size bloats with regards to eh_frame, the reasoning is similar. > Restricting the section creation to only basic blocks that have profiles will > reduce this a lot more. > > Importantly, if CFI support were available for discontiguous ranges we wouldn't > have to duplicate CFI FDEs and the bloats would be near minimal. > > BOLT parses CFI and DWARF and generates compact information by rewriting it. > Whereas, Propeller uses lld which uses relocations and sections to fixup but > does not rewrite it. This is by...

...gt; > Also for object size bloats with regards to eh_frame, the reasoning is similar. > > > Restricting the section creation to only basic blocks that have profiles will > > > reduce this a lot more. > > > > > > Importantly, if CFI support were available for discontiguous ranges we wouldn't > > > have to duplicate CFI FDEs and the bloats would be near minimal. > > > > > > BOLT parses CFI and DWARF and generates compact information by rewriting it. > > > Whereas, Propeller uses lld which uses relocations and sections to fixup b...

...ss, ocfs2 has had a major limitation since the beginning. When ocfs2 needs new inodes, it has always grown its metadata allocators in contiguous hunks. As you might expect, badly fragmented filesystems may be unable to add new inodes even when there is plenty of unused space. Tao and I have added discontiguous block groups to fix the problem. There's also various small stuff. The shortlog is below. Please pull. Joel The following changes since commit a0fe3cc5d36a5f5b4f60abfe1a4b1caf4a5cce5a: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input ar...

...This is just to remind users to add the "noatime" mount option to the mounts that hold the Oracle datafiles, redologs, archivelogs, voting file, etc. This is for OCFS2 1.4 only. WHAT'S CHANGED This release includes bug fixes, applicable backports from mainline and a new feature discontiguous block group. The new feature allows block groups to allocate discontiguous groups when contiguous region is not available. To enable discontigous block group feature # tunefs.ocfs2 --fs-features=discontig-bg <dev> To disable discontigous block group feature # tunefs.ocfs2 --fs-fe...

...Re: [llvm-dev] [RFC] Propeller: A frame work for Post Link > Optimizations > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same > CFI bloat issue? From my cursory reading of the propellor doc, the CFI > duplication is _necessary_ to represent discontiguous functions, not > anything particular to the way Propellor happens to generate those > discontiguous functions. > > > > And emitting discontiguous functions is a fundamental goal of this, right? > > > > On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko via llvm-dev < &...

That change converted the (wrong) assumption of contiguous nodes'' memory to a similarly wrong one of assuming discontiguous memory (i.e. each node having separate E820 table entries). The code ought to be able to deal with both, though, and I hope this change makes it so. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2009-08-24.orig/xen/arch/x86/srat.c 2009-08-28 00:00:00.000000000 +0200 +++ 2009-08-24/xe...

On Wed, Oct 2, 2019 at 8:41 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > *Pessimization/overhead for stack unwinding used by system-wide profilers > and > for exception handling* > > Larger CFI programs put an extra burden on unwinding at runtime as more CFI > (and thus native) instructions have to be executed. This will cause more > overhead

...nk >>> Optimizations >>> >>> >>> >>> I'm a bit confused by this subthread -- doesn't BOLT have the exact same >>> CFI bloat issue? From my cursory reading of the propellor doc, the CFI >>> duplication is _necessary_ to represent discontiguous functions, not >>> anything particular to the way Propellor happens to generate those >>> discontiguous functions. >>> >>> >>> >>> And emitting discontiguous functions is a fundamental goal of this, >>> right? >>> >>>...

...and PGO passes suffer from profile imprecision. + Updated DebugInfo and CFI to account for arbitrary ordering of basic blocks via basic block sections. + Discussed CFI handling and is sub-optimal and bloats object file sizes and binary sizes much more than DebugInfo due to lack of support for discontiguous address ranges. We have talked about this and would like to make a case to support discontiguous ranges with CFI which will make basic block sections much more cheaper. Detailed RFC document here : https://github.com/google/llvm-propeller/blob/plo-dev/Propeller_RFC.pdf Please let us know what yo...

...Re: [llvm-dev] [RFC] Propeller: A frame work for Post Link > Optimizations > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same > CFI bloat issue? From my cursory reading of the propellor doc, the CFI > duplication is _necessary_ to represent discontiguous functions, not > anything particular to the way Propellor happens to generate those > discontiguous functions. > > > > And emitting discontiguous functions is a fundamental goal of this, right? > > > > On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko via llvm-dev < &...

...Re: [llvm-dev] [RFC] Propeller: A frame work for Post Link > Optimizations > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same > CFI bloat issue? From my cursory reading of the propellor doc, the CFI > duplication is _necessary_ to represent discontiguous functions, not > anything particular to the way Propellor happens to generate those > discontiguous functions. > > > > And emitting discontiguous functions is a fundamental goal of this, right? > > > > On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko via llvm-dev < &...

...of the EH work. It seems like it would be a more consistent design for SEH to do the same. > > Having a single combined MachineFunction also means that MI passes will have to learn more about SEH. For example, we need to preserve the ordering of basic blocks so that we don't end up with discontiguous regions of code. Yes, you would probably need to do that. It doesn’t seem like that would be fundamentally difficult, but I haven’t thought through the details and I can imagine that it would take a fair bit of work. -------------- next part -------------- An HTML attachment was scrubbed... URL: &...

...list of variable length records where records, or even individual fields of records might cross a block boundary and require multiple reads to piece together. I needed a way to view these streams as being contiguous, and reading data out of them allowing all the magic of broken fields and records, discontiguous records, etc to just disappear behind the interface. Also, I needed the ability to read and write using a single interface without worrying about the details of the block structure. None of LLVM's existing abstractions provided convenient mechanisms for writing this kind of data. So I came u...

...Re: [llvm-dev] [RFC] Propeller: A frame work for Post Link > Optimizations > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same > CFI bloat issue? From my cursory reading of the propellor doc, the CFI > duplication is _necessary_ to represent discontiguous functions, not > anything particular to the way Propellor happens to generate those > discontiguous functions. > > > > And emitting discontiguous functions is a fundamental goal of this, right? > > > > On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko via llvm-dev < &...

The patchset will add basic NUMA support to Xen (hypervisor only). We borrowed from Linux support for NUMA SRAT table parsing, discontiguous memory tracking (mem chunks), and cpu support (node_to_cpumask etc). The hypervisor parses the SRAT tables and constructs mappings for each node such as node to cpu mappings and memory range to node mappings. Using this information, we also modified the page allocator to provide a simple NUMA-awa...

We currently compare the sum of the pages found in the SRAT table to the address of the highest memory page found via the e820 table to validate the SRAT. This is completely bogus if there''s any kind of discontiguous memory, where the sum of the pages could be much smaller than the address of the highest page. I think all that''s necessary is to validate that each usable memory range in the e820 is covered by an SRAT entry. This might not be the most efficient way to do it, but there are usually a rel...

...e a frame pointer, such as rbp,       though it doesn't have to be rbp and often is not.              There is also a notion of chaining the data. This is useful when       a function has "early out" paths that only change some non volatiles.              Also there is allowance for discontiguous functions.              Also there is no metadata for epilogues. If an exception occurs in an epilogue,       the runtime actually look at the code being run, detects it is an epilogue       and simulates it. As such, epilogue code generation is constrained.       (and breakpoints within epilogues...

...ht you were going to say that the front-end needed to decide what goes in the capture block. >> Having a single combined MachineFunction also means that MI passes will have to learn more about SEH. For example, we need to preserve the ordering of basic blocks so that we don't end up with discontiguous regions of code. > > Yes, you would probably need to do that. It doesn’t seem like that would be fundamentally difficult, but I haven’t thought through the details and I can imagine that it would take a fair bit of work. > -------------- next part -------------- An HTML attachment was s...

...The second fix will also help existing volumes. The final fix for this problem will be provided in the next patch update (1.4.8). In it, we will allow the block allocators (inode and extent) to be grown even when a 4MB contiguous chunk is not available. Users will be able to activate this feature (discontiguous block groups) on existing volumes. This feature is currently in testing. BUGS FIXED ossbz#970 Unfair postponement of local lock requests (Livelock) ossbz#1175 BUG in dlm_free_dead_locks() (Oops during dlm recovery) ossbz#1178 BUG in ocfs2_prepare_downconvert() (Oops during downconvert) ossbz#118...