aboutsummaryrefslogtreecommitdiff
path: root/src/pkg/runtime/proc.c
AgeCommit message (Collapse)Author
2013-07-17runtime: disable preemption again to fix linux buildIan Lance Taylor
Otherwise the tests in pkg/runtime fail: runtime: unknown argument frame size for runtime.deferreturn called from 0x48657b [runtime_test.func·022] fatal error: invalid stack ... R=golang-dev, dave CC=golang-dev https://golang.org/cl/11483043
2013-07-17runtime: re-enable preemptionRuss Cox
Update #543 I believe the runtime is strong enough now to reenable preemption during the function prologue. Assuming this is or can be made stable, it will be in Go 1.2. More aggressive preemption is not planned for Go 1.2. R=golang-dev, iant CC=golang-dev https://golang.org/cl/11433045
2013-07-17runtime: more reliable preemptionDmitriy Vyukov
Currently preemption signal g->stackguard0==StackPreempt can be lost if it is received when preemption is disabled (e.g. m->lock!=0). This change duplicates the preemption signal in g->preempt and restores g->stackguard0 when preemption is enabled. Update #543. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10792043
2013-07-17runtime: use new frame argument size informationRuss Cox
With this CL, I believe the runtime always knows the frame size during the gc walk. There is no fallback to "assume entire stack frame of caller" anymore. R=golang-dev, khr, cshapiro, dvyukov CC=golang-dev https://golang.org/cl/11374044
2013-07-11runtime: fix CPU underutilizationDmitriy Vyukov
runtime.newproc/ready are deliberately sloppy about waking new M's, they only ensure that there is at least 1 spinning M. Currently to compensate for that, schedule() checks if the current P has local work and there are no spinning M's, it wakes up another one. It does not work if goroutines do not call schedule. With this change a spinning M wakes up another M when it finds work to do. It's also not ideal, but it fixes the underutilization. A proper check would require to know the exact number of runnable G's, but it's too expensive to maintain. Fixes #5586. This is reincarnation of cl/9776044 with the bug fixed. The bug was due to code added after cl/9776044 was created: if(tick - (((uint64)tick*0x4325c53fu)>>36)*61 == 0 && runtime·sched.runqsize > 0) { runtime·lock(&runtime·sched); gp = globrunqget(m->p, 1); runtime·unlock(&runtime·sched); } If M gets gp from global runq here, it does not reset m->spinning. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10743044
2013-07-01runtime: disable preemptionRuss Cox
There are various problems, and both Dmitriy and I will be away for the next week. Make the runtime a bit more stable while we're gone. R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/10848043
2013-06-28runtime: introduce GODEBUG env varDmitriy Vyukov
Currently it replaces GOGCTRACE env var (GODEBUG=gctrace=1). The plan is to extend it with other type of debug tracing, e.g. GODEBUG=gctrace=1,schedtrace=100. R=rsc CC=bradfitz, daniel.morsing, gobot, golang-dev https://golang.org/cl/10026045
2013-06-28runtime: preempt goroutines for GCDmitriy Vyukov
The last patch for preemptive scheduler, with this change stoptheworld issues preemption requests every 100us. Update #543. R=golang-dev, daniel.morsing, rsc CC=golang-dev https://golang.org/cl/10264044
2013-06-27runtime: remove declaration of function that does not existIan Lance Taylor
R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/10730045
2013-06-27undo CL 9776044 / 1e280889f997Dmitriy Vyukov
Failure on bot: http://build.golang.org/log/f4c648906e1289ec2237c1d0880fb1a8b1852a08 ««« original CL description runtime: fix CPU underutilization runtime.newproc/ready are deliberately sloppy about waking new M's, they only ensure that there is at least 1 spinning M. Currently to compensate for that, schedule() checks if the current P has local work and there are no spinning M's, it wakes up another one. It does not work if goroutines do not call schedule. With this change a spinning M wakes up another M when it finds work to do. It's also not ideal, but it fixes the underutilization. A proper check would require to know the exact number of runnable G's, but it's too expensive to maintain. Fixes #5586. R=rsc TBR=rsc CC=gobot, golang-dev https://golang.org/cl/9776044 »»» R=golang-dev CC=golang-dev https://golang.org/cl/10692043
2013-06-27runtime: fix CPU underutilizationDmitriy Vyukov
runtime.newproc/ready are deliberately sloppy about waking new M's, they only ensure that there is at least 1 spinning M. Currently to compensate for that, schedule() checks if the current P has local work and there are no spinning M's, it wakes up another one. It does not work if goroutines do not call schedule. With this change a spinning M wakes up another M when it finds work to do. It's also not ideal, but it fixes the underutilization. A proper check would require to know the exact number of runnable G's, but it's too expensive to maintain. Fixes #5586. R=rsc CC=gobot, golang-dev https://golang.org/cl/9776044
2013-06-27runtime: record proper goroutine state during stack splitRuss Cox
Until now, the goroutine state has been scattered during the execution of newstack and oldstack. It's all there, and those routines know how to get back to a working goroutine, but other pieces of the system, like stack traces, do not. If something does interrupt the newstack or oldstack execution, the rest of the system can't understand the goroutine. For example, if newstack decides there is an overflow and calls throw, the stack tracer wouldn't dump the goroutine correctly. For newstack to save a useful state snapshot, it needs to be able to rewind the PC in the function that triggered the split back to the beginning of the function. (The PC is a few instructions in, just after the call to morestack.) To make that possible, we change the prologues to insert a jmp back to the beginning of the function after the call to morestack. That is, the prologue used to be roughly: TEXT myfunc check for split jmpcond nosplit call morestack nosplit: sub $xxx, sp Now an extra instruction is inserted after the call: TEXT myfunc start: check for split jmpcond nosplit call morestack jmp start nosplit: sub $xxx, sp The jmp is not executed directly. It is decoded and simulated by runtime.rewindmorestack to discover the beginning of the function, and then the call to morestack returns directly to the start label instead of to the jump instruction. So logically the jmp is still executed, just not by the cpu. The prologue thus repeats in the case of a function that needs a stack split, but against the cost of the split itself, the extra few instructions are noise. The repeated prologue has the nice effect of making a stack split double-check that the new stack is big enough: if morestack happens to return on a too-small stack, we'll now notice before corruption happens. The ability for newstack to rewind to the beginning of the function should help preemption too. If newstack decides that it was called for preemption instead of a stack split, it now has the goroutine state correctly paused if rescheduling is needed, and when the goroutine can run again, it can return to the start label on its original stack and re-execute the split check. Here is an example of a split stack overflow showing the full trace, without any special cases in the stack printer. (This one was triggered by making the split check incorrect.) runtime: newstack framesize=0x0 argsize=0x18 sp=0x6aebd0 stack=[0x6b0000, 0x6b0fa0] morebuf={pc:0x69f5b sp:0x6aebd8 lr:0x0} sched={pc:0x68880 sp:0x6aebd0 lr:0x0 ctxt:0x34e700} runtime: split stack overflow: 0x6aebd0 < 0x6b0000 fatal error: runtime: split stack overflow goroutine 1 [stack split]: runtime.mallocgc(0x290, 0x100000000, 0x1) /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:21 fp=0x6aebd8 runtime.new() /Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:682 +0x5b fp=0x6aec08 go/build.(*Context).Import(0x5ae340, 0xc210030c71, 0xa, 0xc2100b4380, 0x1b, ...) /Users/rsc/g/go/src/pkg/go/build/build.go:424 +0x3a fp=0x6b00a0 main.loadImport(0xc210030c71, 0xa, 0xc2100b4380, 0x1b, 0xc2100b42c0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:249 +0x371 fp=0x6b01a8 main.(*Package).load(0xc21017c800, 0xc2100b42c0, 0xc2101828c0, 0x0, 0x0, ...) /Users/rsc/g/go/src/cmd/go/pkg.go:431 +0x2801 fp=0x6b0c98 main.loadPackage(0x369040, 0x7, 0xc2100b42c0, 0x0) /Users/rsc/g/go/src/cmd/go/pkg.go:709 +0x857 fp=0x6b0f80 ----- stack segment boundary ----- main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc2100e6c00, 0xc2100e5750, ...) /Users/rsc/g/go/src/cmd/go/build.go:539 +0x437 fp=0x6b14a0 main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc21015b400, 0x2, ...) /Users/rsc/g/go/src/cmd/go/build.go:528 +0x1d2 fp=0x6b1658 main.(*builder).test(0xc2100902a0, 0xc210092000, 0x0, 0x0, 0xc21008ff60, ...) /Users/rsc/g/go/src/cmd/go/test.go:622 +0x1b53 fp=0x6b1f68 ----- stack segment boundary ----- main.runTest(0x5a6b20, 0xc21000a020, 0x2, 0x2) /Users/rsc/g/go/src/cmd/go/test.go:366 +0xd09 fp=0x6a5cf0 main.main() /Users/rsc/g/go/src/cmd/go/main.go:161 +0x4f9 fp=0x6a5f78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:183 +0x92 fp=0x6a5fa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1266 fp=0x6a5fa8 And here is a seg fault during oldstack: SIGSEGV: segmentation violation PC=0x1b2a6 runtime.oldstack() /Users/rsc/g/go/src/pkg/runtime/stack.c:159 +0x76 runtime.lessstack() /Users/rsc/g/go/src/pkg/runtime/asm_amd64.s:270 +0x22 goroutine 1 [stack unsplit]: fmt.(*pp).printArg(0x2102e64e0, 0xe5c80, 0x2102c9220, 0x73, 0x0, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:818 +0x3d3 fp=0x221031e6f8 fmt.(*pp).doPrintf(0x2102e64e0, 0x12fb20, 0x2, 0x221031eb98, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:1183 +0x15cb fp=0x221031eaf0 fmt.Sprintf(0x12fb20, 0x2, 0x221031eb98, 0x1, 0x1, ...) /Users/rsc/g/go/src/pkg/fmt/print.go:234 +0x67 fp=0x221031eb40 flag.(*stringValue).String(0x2102c9210, 0x1, 0x0) /Users/rsc/g/go/src/pkg/flag/flag.go:180 +0xb3 fp=0x221031ebb0 flag.(*FlagSet).Var(0x2102f6000, 0x293d38, 0x2102c9210, 0x143490, 0xa, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:633 +0x40 fp=0x221031eca0 flag.(*FlagSet).StringVar(0x2102f6000, 0x2102c9210, 0x143490, 0xa, 0x12fa60, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:550 +0x91 fp=0x221031ece8 flag.(*FlagSet).String(0x2102f6000, 0x143490, 0xa, 0x12fa60, 0x0, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:563 +0x87 fp=0x221031ed38 flag.String(0x143490, 0xa, 0x12fa60, 0x0, 0x161950, ...) /Users/rsc/g/go/src/pkg/flag/flag.go:570 +0x6b fp=0x221031ed80 testing.init() /Users/rsc/g/go/src/pkg/testing/testing.go:-531 +0xbb fp=0x221031edc0 strings_test.init() /Users/rsc/g/go/src/pkg/strings/strings_test.go:1115 +0x62 fp=0x221031ef70 main.init() strings/_test/_testmain.go:90 +0x3d fp=0x221031ef78 runtime.main() /Users/rsc/g/go/src/pkg/runtime/proc.c:180 +0x8a fp=0x221031efa0 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 fp=0x221031efa8 goroutine 2 [runnable]: runtime.MHeap_Scavenger() /Users/rsc/g/go/src/pkg/runtime/mheap.c:438 runtime.goexit() /Users/rsc/g/go/src/pkg/runtime/proc.c:1269 created by runtime.main /Users/rsc/g/go/src/pkg/runtime/proc.c:166 rax 0x23ccc0 rbx 0x23ccc0 rcx 0x0 rdx 0x38 rdi 0x2102c0170 rsi 0x221032cfe0 rbp 0x221032cfa0 rsp 0x7fff5fbff5b0 r8 0x2102c0120 r9 0x221032cfa0 r10 0x221032c000 r11 0x104ce8 r12 0xe5c80 r13 0x1be82baac718 r14 0x13091135f7d69200 r15 0x0 rip 0x1b2a6 rflags 0x10246 cs 0x2b fs 0x0 gs 0x0 Fixes #5723. R=r, dvyukov, go.peter.90, dave, iant CC=golang-dev https://golang.org/cl/10360048
2013-06-15runtime: improve scheduler fairnessDmitriy Vyukov
Currently global runqueue is starved if a group of goroutines constantly respawn each other (local runqueue never becomes empty). Fixes #5639. R=golang-dev, iant CC=golang-dev https://golang.org/cl/10042044
2013-06-12runtime: add lr, ctxt, ret to GobufRuss Cox
Add gostartcall and gostartcallfn. The old gogocall = gostartcall + gogo. The old gogocallfn = gostartcallfn + gogo. R=dvyukov, minux.ma CC=golang-dev https://golang.org/cl/10036044
2013-06-12runtime: fix scheduler race conditionDmitriy Vyukov
In starttheworld() we assume that P's with local work are situated in the beginning of idle P list. However, once we start the first M, it can execute all local G's and steal G's from other P's. That breaks the assumption above. Thus starttheworld() will fail to start some P's with local work. It seems that it can not lead to very bad things, but still it's wrong and breaks other assumtions (e.g. we can have a spinning M with local work). The fix is to collect all P's with local work first, and only then start them. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/10051045
2013-06-12runtime: adjust traceback / garbage collector boundaryRuss Cox
The garbage collection routine addframeroots is duplicating logic in the traceback routine that calls it, sometimes correctly, sometimes incorrectly, sometimes incompletely. Pass necessary information to addframeroots instead of deriving it anew. Should make addframeroots significantly more robust. It's certainly smaller. Also try to standardize on uintptr for saved pc, sp values. Will make CL 10036044 trivial. R=golang-dev, dave, dvyukov CC=golang-dev https://golang.org/cl/10169045
2013-06-06runtime: remove unused mid functionIan Lance Taylor
R=golang-dev, r CC=golang-dev https://golang.org/cl/10036047
2013-06-03runtime: disable preemption in several scheduler functionsDmitriy Vyukov
Required for preemptive scheduler, see the comments for details. R=golang-dev, khr, iant, khr CC=golang-dev https://golang.org/cl/9740051
2013-06-03runtime: introduce preemption function (not used for now)Dmitriy Vyukov
This is part of preemptive scheduler. R=golang-dev, cshapiro, iant CC=golang-dev https://golang.org/cl/9843046
2013-06-03runtime: add stackguard0 to GDmitriy Vyukov
This is part of preemptive scheduler. stackguard0 is checked in split stack checks and can be set to StackPreempt. stackguard is not set to StackPreempt (holds the original value). R=golang-dev, daniel.morsing, iant CC=golang-dev https://golang.org/cl/9875043
2013-05-30runtime: mark runtime.goexit as nosplitDmitriy Vyukov
Required for preemptive scheduler, see the comment. R=golang-dev, daniel.morsing CC=golang-dev https://golang.org/cl/9841047
2013-05-28runtime: allocate internal symbol table eagerlyDmitriy Vyukov
we need it for GC anyway. R=golang-dev, khr, dave, khr CC=golang-dev https://golang.org/cl/9728044
2013-05-22runtime: detect deadlocks in programs using cgoDmitriy Vyukov
When cgo is used, runtime creates an additional M to handle callbacks on threads not created by Go. This effectively disabled deadlock detection, which is a right thing, because Go program can be blocked and only serve callbacks on external threads. This also disables deadlock detection under race detector, because it happens to use cgo. With this change the additional M is created lazily on first cgo call. So deadlock detector works for programs that import "C", "net" or "net/http/pprof" but do not use them in fact. Also fixes deadlock detector under race detector. It should be fine to create the M later, because C code can not call into Go before first cgo call, because C code does not know when Go initialization has completed. So a Go program need to call into C first either to create an external thread, or notify a thread created in global ctor that Go initialization has completed. Fixes #4973. Fixes #5475. R=golang-dev, minux.ma, iant CC=golang-dev https://golang.org/cl/9303046
2013-05-20runtime: zeroize g->fnstart to not prevent GC of the closureDmitriy Vyukov
Fixes #5493. R=golang-dev, minux.ma, iant CC=golang-dev https://golang.org/cl/9557043
2013-05-19runtime: properly set G status after syscallDmitriy Vyukov
R=golang-dev, r, dave CC=golang-dev https://golang.org/cl/9307045
2013-05-18runtime: fix newproc debugging printAnthony Martin
R=golang-dev, remyoudompheng, r CC=golang-dev https://golang.org/cl/9249044
2013-04-06runtime: fix deadlock in network pollerDmitriy Vyukov
The invariant is that there must be at least one running P or a thread polling network. It was broken. Fixes #5216. R=golang-dev, bradfitz, r CC=golang-dev https://golang.org/cl/8459043
2013-04-06runtime: reset dangling typed pointerDmitriy Vyukov
+untype it because it can point to different types Update #5193. R=golang-dev, iant CC=golang-dev https://golang.org/cl/8454043
2013-04-06runtime: reset typed dangling pointerDmitriy Vyukov
If for whatever reason seh points into Go heap region, the dangling pointer will cause memory corruption during GC. Update #5193. R=golang-dev, alex.brainman, iant CC=golang-dev https://golang.org/cl/8402045
2013-03-28cmd/ld, runtime: restrict stack root scan to locals and argumentsCarl Shapiro
Updates #5134 R=golang-dev, bradfitz, cshapiro, daniel.morsing, ality, iant CC=golang-dev https://golang.org/cl/8022044
2013-03-21runtime: faster parallel GCDmitriy Vyukov
Use per-thread work buffers instead of global mutex-protected pool. This eliminates contention from parallel scan phase. benchmark old ns/op new ns/op delta garbage.BenchmarkTree2-8 97100768 71417553 -26.45% garbage.BenchmarkTree2LastPause-8 970931485 714103692 -26.45% garbage.BenchmarkTree2Pause-8 469127802 345029253 -26.45% garbage.BenchmarkParser-8 2880950854 2715456901 -5.74% garbage.BenchmarkParserLastPause-8 137047399 103336476 -24.60% garbage.BenchmarkParserPause-8 80686028 58922680 -26.97% R=golang-dev, 0xe2.0x9a.0x9b, dave, adg, rsc, iant CC=golang-dev https://golang.org/cl/7816044
2013-03-15runtime: accept GOTRACEBACK=crash to mean 'crash after panic'Russ Cox
This provides a way to generate core dumps when people need them. The settings are: GOTRACEBACK=0 no traceback on panic, just exit GOTRACEBACK=1 default - traceback on panic, then exit GOTRACEBACK=2 traceback including runtime frames on panic, then exit GOTRACEBACK=crash traceback including runtime frames on panic, then crash Fixes #3257. R=golang-dev, devon.odell, r, daniel.morsing, ality CC=golang-dev https://golang.org/cl/7666044
2013-03-12runtime: add network polling support into schedulerDmitriy Vyukov
This is a part of the bigger change that moves network poller into runtime: https://golang.org/cl/7326051/ R=golang-dev, bradfitz, mikioh.mikioh, rsc CC=golang-dev https://golang.org/cl/7448048
2013-03-12runtime: fix deadlock detector false negativeDmitriy Vyukov
The issue was that scvg is assigned *after* the scavenger goroutine is started, so when the scavenger calls entersyscall() the g==scvg check can fail. Fixes #5025. R=golang-dev, iant CC=golang-dev https://golang.org/cl/7629045
2013-03-08runtime: clear locked bit when goroutine exitsRuss Cox
Otherwise the next goroutine run on the m can get inadvertently locked if it executes a cgo call that turns on the internal lock. While we're here, fix the cgo panic unwind to decrement m->ncgo like the non-panic unwind does. Fixes #4971. R=golang-dev, iant, dvyukov CC=golang-dev https://golang.org/cl/7627043
2013-03-07runtime: fix deadlockDmitriy Vyukov
The deadlock episodically occurs on misc/cgo/test/TestCthread. The problem is that starttheworld() leaves some P's with local work without M's. Then all active M's enter into syscalls, but reject to wake another M's due to the following check (both in entersyscallblock() and in retake()): if(p->runqhead == p->runqtail && runtime·atomicload(&runtime·sched.nmspinning) + runtime·atomicload(&runtime·sched.npidle) > 0) continue; R=rsc CC=golang-dev https://golang.org/cl/7424054
2013-03-05undo CL 7301062 / 9742f722b558Russ Cox
broke arm garbage collector traceback_arm fails with a missing pc. It needs CL 7494043. But that only makes the build break later, this time with "invalid freelist". Roll back until it can be fixed correctly. ««« original CL description runtime: restrict stack root scan to locals and arguments R=rsc CC=golang-dev https://golang.org/cl/7301062 »»» R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/7493044
2013-03-04runtime: restrict stack root scan to locals and argumentsCarl Shapiro
R=rsc CC=golang-dev https://golang.org/cl/7301062
2013-03-04runtime: add link to design doc for new schedulerRuss Cox
R=golang-dev, remyoudompheng, bradfitz CC=golang-dev https://golang.org/cl/7419049
2013-03-01runtime: add atomics to fix armRuss Cox
R=golang-dev, minux.ma CC=golang-dev https://golang.org/cl/7429046
2013-03-01runtime: start all threads with runtime.mstartRuss Cox
Putting the M initialization in multiple places will not scale. Various code assumes mstart is the start already. Make it so. R=golang-dev, devon.odell CC=golang-dev https://golang.org/cl/7420048
2013-03-01runtime: improved schedulerDmitriy Vyukov
Distribute runnable queues, memory cache and cache of dead G's per processor. Faster non-blocking syscall enter/exit. More conservative worker thread blocking/unblocking. R=dave, bradfitz, remyoudompheng, rsc CC=golang-dev https://golang.org/cl/7314062
2013-02-28runtime/cgo: make symbol naming consistentRuss Cox
The naming in this package is a disaster. Make it all consistent. Remove some 'static' from functions that will be referred to from other files soon. This CL is purely renames using global search and replace. Submitting separately so that real changes will not be drowned out by these renames in future CLs. TBR=iant CC=golang-dev https://golang.org/cl/7416046
2013-02-27runtime: more changes in preparation to the new schedulerDmitriy Vyukov
add per-P cache of dead G's add global runnable queue (not used for now) add list of idle P's (not used for now) R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7397061
2013-02-23runtime: fix windows cpu profilingDmitriy Vyukov
R=golang-dev, alex.brainman CC=golang-dev https://golang.org/cl/7407044
2013-02-23runtime: implement local work queues (in preparation for new scheduler)Dmitriy Vyukov
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7402047
2013-02-23runtime: minor changesDmitriy Vyukov
to minimize diffs of new scheduler R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7381048
2013-02-21cmd/gc, reflect, runtime: switch to indirect func value representationRuss Cox
Step 1 of http://golang.org/s/go11func. R=golang-dev, r, daniel.morsing, remyoudompheng CC=golang-dev https://golang.org/cl/7393045
2013-02-21runtime: fix heap corruptionDmitriy Vyukov
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7397049
2013-02-21runtime: split minit() to mpreinit() and minit()Dmitriy Vyukov
mpreinit() is called on the parent thread and with mcache (can allocate memory), minit() is called on the child thread and can not allocate memory. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/7389043
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 11:08:01 +0000