search for: subthreads

(This subthread is more appropriate to -users than to -dev, so it is crossposted only to mark its transition. Please reply on the -user list only.) What are the cheapest prices for (humans) transcribing voicemail to text as a service? The absolute cheapest, regardless of (known) quality - the quality only has to compete with (cheaper) automated transcription, which is abysmal quality. On Wed,

...ndex dfc357614e56..958d2972313f 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -126,7 +126,7 @@ static bool oom_cpuset_eligible(struct task_struct *tsk, struct oom_control *oc) /* * The process p may have detached its own ->mm while exiting or through - * use_mm(), but one or more of its subthreads may still have a valid + * kthread_use_mm(), but one or more of its subthreads may still have a valid * pointer. Return p, or any of its subthreads with a valid ->mm, with * task_lock() held. */ @@ -919,8 +919,8 @@ static void __oom_kill_process(struct task_struct *victim, const char *mes...

...ndex dfc357614e56..958d2972313f 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -126,7 +126,7 @@ static bool oom_cpuset_eligible(struct task_struct *tsk, struct oom_control *oc) /* * The process p may have detached its own ->mm while exiting or through - * use_mm(), but one or more of its subthreads may still have a valid + * kthread_use_mm(), but one or more of its subthreads may still have a valid * pointer. Return p, or any of its subthreads with a valid ->mm, with * task_lock() held. */ @@ -919,8 +919,8 @@ static void __oom_kill_process(struct task_struct *victim, const char *mes...

...re remarked available_externally. For a non-discardable symbol that was imported, we can discard here since we are done with inlining (it is non-discardable in its home module)." &, like Duncan, I'll wait for more details on that front. (may or may not be useful to split some of these subthreads into separate email threads to keep discussion clear - but I'm not sure) > > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/b6ba7050/attachment.html>

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,

On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly interesting. > > > > FWIW, we also have a case where a customer wants '-fno-associative-math' > to suppress reassociation under '-ffastmath'. It would take me a while > to find the specifics of the issue, but it was

...discardable symbol that was imported, we can discard here since we > > are done with inlining (it is non-discardable in its home module)." > > > > &, like Duncan, I'll wait for more details on that front. (may or may > not be > > useful to split some of these subthreads into separate email threads to > keep > > discussion clear - but I'm not sure) > > I just went back and looked at my prototype and I had remembered this > wrong. An imported function is always marked > AvailableExternallyLinkage, unless it has link once linkage. > > A...

> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

Ian Campbell <ijc at hellion.org.uk> writes: #Was that with the Jessie or Wheezy dom0 kernel? Actually tried both kernels. 3.13 on Jessie and 3.2 on Wheezy. The keyboard failed on any xen 4.3 boot. If it was nonxen, or xen 4.1 on any kernel the keyboard worked normal. Thanks for your help troubleshooting. Cheers, Mike -------------- next part -------------- An HTML attachment was

On Mon, Jul 06, 2020 at 05:08:20PM +0100, Dave Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > new file mode 100644 > > index 000000000000..515e360b01a1 > > --- /dev/null > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -0,0 +1,63 @@ > >

(This subthread is more appropriate to -users than to -dev, so it is crossposted only to mark its transition. Please reply on the -user list only.) What are the cheapest prices for (humans) transcribing voicemail to text as a service? The absolute cheapest, regardless of (known) quality - the quality only has to compete with (cheaper) automated transcription, which is abysmal quality. On Wed,

We would also like to clarify on the misconceptions around CFI Instructions: There are two things that need to be clarified here: 1) Extra CFI FDE entries for basic blocks does not mean more dynamic instructions are executed. In fact, they do not increase at all. Krys talked about this earlier. 2) We do deduplication of common static CFI instructions in the FDE and move it to the CIE . Hence,

If we take this argument to its end: any one of those relaxed FP settings *guarantees* that we cannot ensure that the result will be the same between two versions of clang. Therefore, we can no-op all of them, and greatly simplify the optimizer. I know that's not what you're advocating, but the suggestion that we remove 'arcp' is the first step on that path. We can't do that.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi all, this series improves the use_mm / unuse_mm interface by better documenting the assumptions, and my taking the set_fs manipulations spread over the callers into the core API.

Hi, > > +static int virtinput_send_status(struct virtio_input *vi, > > + u16 type, u16 code, s32 value) > > +{ > > + struct virtio_input_event *stsbuf; > > + struct scatterlist sg[1]; > > + > > + stsbuf = kzalloc(sizeof(*stsbuf), GFP_ATOMIC); > > + if (!stsbuf) > > + return -ENOMEM; > > Does this return an error to userspace? >

Hi, > > +static int virtinput_send_status(struct virtio_input *vi, > > + u16 type, u16 code, s32 value) > > +{ > > + struct virtio_input_event *stsbuf; > > + struct scatterlist sg[1]; > > + > > + stsbuf = kzalloc(sizeof(*stsbuf), GFP_ATOMIC); > > + if (!stsbuf) > > + return -ENOMEM; > > Does this return an error to userspace? >

Apply the ideas in the previous patch to the C-language bindings generator. Signed-off-by: Laszlo Ersek <lersek at redhat.com> --- generator/C.ml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/generator/C.ml b/generator/C.ml index f9171996dde0..07c924c48ccf 100644 --- a/generator/C.ml +++ b/generator/C.ml @@ -250,15 +250,15 @@ let *)

On Wed, Oct 16, 2013 at 9:10 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> >> On Wed, Oct 16, 2013 at 1:21 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> There are a few places where we break the assumption: